[RFC] Pivot to Web Components?

[auniverseaway]

Many moons ago (April 2022) the Milo team decided to use Preact as our preferred SPA framework.

The benefits at the time were obvious:

1. Small footprint.
2. Buildless.
3. React-like API most engineers were already comfortable with.

We chose Preact over Web Components for a couple reasons:

1. To get good reactivity, you need a framework like Lit.
2. WCs have a poor CSS developer experience.
3. WCs + Lit + CSS could introduce performance issues.

Recently the Commerce / Warriors team shipped visitor-facing Web Components and I think it's worth chiming in on this decision (I don't recall an RFC discussion).

The short version is that I think as an org, we should probably move to Web Components for our SPA needs.

I may disagree with shipping WCs to visitors when extreme reactivity or state management is not needed (boring static cards), but I think for our SPA use cases, we should probably pivot away from Preact and move onto Web Components. Why?

1. You can now use Lit in buildless environments.
2. The CSS DX and performance issues have been mostly solved for modern browsers (Safari 16.4+).
3. You will get similar performance to Preact and sometimes better performance.
4. The company and AEM teams are largely moving to Web Components.

I've been doing some prototyping to compare and contrast w/ Preact and while there is a bit of ramp up as it relates to shadowDom and scoping, I think there's enough advantages now to outweigh the disadvantages.

As we start to have more interest from outside teams (everyone from Spectrum to AEM to actual customers) having a standardized approach that can span orgs is better for all of us. It will make contributing to product teams easier. It will make sharing guidance on performance easier because we are all speaking the same language.

Thoughts?

[yesil]

Thanks for bringing this.

Based on our experience with React on Plans/Catalog/TWP pages on Dexter, we identified the following benefits using web-components on Milo:

Authored content by GWP such as paragraphs, images and links can be displayed in the SPA using slots without any further processing while with React we had to parse the markup in DOM, store it as string in the React component state and render it with dangerouslySetInnerHTML.

Although we are currently focused on optimising the UX/performance for Milo, merch web components do not target only Milo, and are designed to be used on other surfaces with different web technologies with ease.

[auniverseaway]

@yesil that's great! I hadn't thought of the slots part and that makes complete sense. Love the DOM re-use.

Something I briefly touched on above was the notion that the CSS / DX / performance issues have been mostly solved (to my satisfaction). This is definitely the case for Chrome-based browsers that support CSS Module Scripts.

Historically, Lit has said to write CSS in JS (🤮), use a link element (perf issue), or some other mechansim.

With FF & Safari supporting adoptedStyleSheets we can still get most of CSS Modules with a little bit of a polyfill. What's nice is that we can essentially write our own de-dupe mechanism so a style is only parsed once. This is helpful for when you have a list item that may be put into the DOM many times.

1. Good DX - Just write your file.css like you always would.
2. Good performance - Not "the best" but super close... no style tag, no link element, de-duped fetching & parsing, small hit for the chain and the header cost.

Step 1 - Create Safari / Firefox CSS Module "Polyfill"

const SHEETS = {};

export default async function getSheet(url) {
  if (SHEETS[url]) return SHEETS[url];
  const resp = await fetch(url);
  const text = await resp.text();
  const sheet = new CSSStyleSheet();
  sheet.replace(text);
  SHEETS[url] = sheet;
  return sheet;
}

Step 2 - Import the polyfill and use it to get a sheet
Note: URL must be relative to the root of the site. You cannot use ./ to my knowledge. Which is good anyway because of the lookup table matching above.

import getSheet from '../../shared/sheet.js';
const sheet = await getSheet('/blocks/edit/da-preview/da-preview.css');

Step 3 - Assign the sheet to the shadowDom

connectedCallback() {
  super.connectedCallback();
  this.shadowRoot.adoptedStyleSheets = [sheet];
}

Notes: if you're using this in a normal block, your block will request a normal block-name.css, I would probably leave this file empty (but still exist) so you can keep all your styles scoped. This is some small overhead in request, headers, response, etc. for an empty file, but I think we can live with it.

[yesil]

We are building web-components in a separate repository and we use esbuild for packaging them for distribution.
For the CSS we adopted filename.css.js approach with vanilla CSS inside, that is imported by filaname.js.
We have good idea support with eslint and good developer experience since we don't depend on any build step for the development experience.
I'm exciting to see web-components being adopted and hopefully we can standardize the approach from end to end.

[npeltier]

what about typescript adoption for web components :) ? i really like lit annotations there, not sure what would be the drawbacks (cc @yesil @auniverseaway )

[mokimo]

Chris had a deep dive into “A discussion on using Web Components for content creation applications." https://www.youtube.com/watch?v=pOQcSir5Tpw - definitely valuable to watch when participating in this conversation

[mokimo]

Here's another relevant discussion that dives into a standardized way of using (Spectrum) Web Components https://github.com/orgs/adobecom/discussions/1618