Replies: 6 comments
-
In my mind, Milo and Boilerplate have different goals with fundamentally different target architectures. As you can see the from the commit history of Milo, we started with Boilerplate and quickly found its architecture was not suitable for a site at the scale of adobe.com. Trying to shoehorn the current boilerplate into solving adobe.com-like problems would result in something a lot like Milo and that would lose the whole premise of "updating" Milo. Maybe put another way: Milo's centralized architecture negates this type "update" for our consumers. When we make a change, every Milo consumer gets this update. Contrast this to boilerplate and your question, consumers of boilerplate must be "udpated" (to use your words) to get latest features and I think that is a significant step backwards. Go look at https://github.com/hlxsites to see how many
If we don't support Target-less A/B testing in MEP, I think that's a miss on our end. I was out of these conversations, but my guess is that leadership wanted the kind of decisioning Target provides at the expense of performance. I think the key word here is "simple A/B testing" as most our A/B testing is not simple. A core Franklin principle is to only build what you use and we don't currently have a need for "simple A/B testing." I do think Milo has consumers (blog) where Target-less / simple A/B testing would be useful, but they have not come to us asking for this feature, yet.
If the DC team wants to go down this route, they are absolutely welcome to do this from my perspective. I think some of our senior leadership may have some concerns from a maintainability perspective (see 2nd paragraph above, styles, re-usable blocks, localization, fragments, etc.), but whatever works best for the project. I don't really consider the Frictionless project a Milo project anyway. They load Milo so far down the call stack, it's basically a custom project since they have to do a lot of things on their own... LCP detection, custom block loading, locale handling, script loading, etc. Last I checked, the only thing they use to get to FCP and LCP is Milo styles. The only thing I would caution, and this really gets to the over-arching question above: boilerplate was not designed for multi-tenancy. The whole concept of shared code doesn't exist. This works very well for singular or small sites that want to get up and running quickly. If you value maintainability, code re-use, instant upgrades, boilerplate falls down. We know this because we have seen it with all boilerplate-like projects that are more than a few months old: Blog, BACOM Blog, Express, and PACOM. Boilerplate itself is a direct descendant of Express and Express never got any of these "several improvements" you're referring to... someone would have to backport them (fact check: no one did). You might shave ~100ms moving to Boilerplate initially, but your project loses features in that 100ms and will need more maintenance in the long run. In most common scenarios, both Milo and Boilerplate are under the threshold of what it takes to get 100 LH and have all green CWV. Here's a quick comparison of Milo and Boilerplate performance... Hope this helps. |
Beta Was this translation helpful? Give feedback.
-
The other thing I would do is to look at other long running projects and see how they've faired with the Boilerplate architecture... AEM's own WKDN: https://pagespeed.web.dev/analysis/https-main--wknd--hlxsites-hlx-live/5kbhl55mdo?form_factor=mobile In the interest of transparency, Milo will never be a consistent 100 LH unless martech is turned off and a reasonable amount (3) of blocks are in LCP, but this should illustrate that boilerplate is no magic bullet for performance (especially long term)... and if DC decides to move, they'll likely be in the same boat as the projects above... they (or you) will be responsible for all performance going forward. Again, they're kinda already there with how they currently use Milo. |
Beta Was this translation helpful? Give feedback.
-
Thanks @auniverseaway for this very detailed and insightful answer. Going back to the 'Simple A/B testing" use-cases which do not require Target (a simple 50/50 split) a need has been expressed in DC. |
Beta Was this translation helpful? Give feedback.
-
@silc007 @auniverseaway I think there is a bit of confusion on what we were actually asking. The point really wasn't whether boilerplate or Milo is better, and I mostly agree to all points Chris is making. Trying to rescope the conversation: at a high level, we all want to ultimately support some form of (1) A/B testing, segmentation and/or personalization, with (2) some consistent reporting and with (3) acceptable performance trade-offs based on the business goals. So breaking this down:
The POC we are trying to run now is to explore how we could leverage a minimal (1) Franklin Experimentation, with (2) RUM data to (3) serve some narrow use cases that require (close to) no performance impact. There were essentially 2 asks on our end to be able to run such a POC for the adobe homepage, and I don't think those go against the Milo core values. It would probably help align both the boilerplate and Milo projects down the road so it's easier to extend both at once when needed without duplicating efforts. So what we discussed with @silc007 was:
Let me know your thoughts |
Beta Was this translation helpful? Give feedback.
-
Cool! If you get with Robert W, I'm sure he would love to support you. @ramboz sorry, wasn't trying to say, "whether boilerplate or Milo is better" only that they both have different goals and to answer the specific question about "performance and features" we may get from boilerplate. Regarding 1: FWIW: I had this conversation in a private chat, but none of our stakeholders (or our engineers) use RUM data. It's fun demo to ask a question in Slack, but our source of truth isn't EDS RUM, it's Google's own CRuX and CWV. We pull our reports directly from Google. I get that other customers may find value in RUM data, but we don't. I also appreciate that the Franklin team wants this data for their own tooling reasons, and I think this is great and it's exactly why we include RUM. Regarding 2:
I think I've mostly already covered this, but I'll try to shine a different light: there were several attempts to get us to use the WKND / Express-based approach to personalization and leadership asked us to go in a different direction that was closer aligned to our existing needs (block level, target based). Again, I'm just the messenger here. From what you're saying, it sounds like it's RUM changes & Target-less personalization you want from boilerplate. I would port these as necessary. We do this all the time with boilerplate features (RUM v1, section metadata). If a project wants to do a full blown Milo + Boilerplate 2023 POC (or move away from Milo), we're happy to assist in any way we can given our capacity. |
Beta Was this translation helpful? Give feedback.
-
@auniverseaway I submitted a PR for 1: #1465 |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I am wondering what it would take to "update" Milo with the latest version of the arm-boilerplate (https://github.com/adobe/aem-boilerplate) in Milo.
Over the past few months, several improvements have been done by the Franklin product team which are providing better performances and new features.
One of them could be very useful to support very simple A/B testing use cases (eg. 2 pages or content tested with a 50/50 split) without the need of having MEP & Target. This feature is lightweight, easy to use and is not impacting performance KPIs.
Franklin team and DC would like to run a POC on one of the Frictionless page.
Any help, advise and Architect review would be greatly appreciated.
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions