Rem recently asked:

“I’m also interested to know if anyone has a hot take on why [Web Components has] taken a decade to get traction.”

Web Components have a marketing problem. I have a lot of opinions about this, so many that I joined the Web Components Community Group.

  1. Too low-level, designed for framework authors. Web Components were designed as a low-level primitive for framework authors, but framework authors were like “nah” because most of their problems were already solved in user-land. Switching to web components and Shadow DOM, despite any performance advantages, would fundamentally upset of some conventions established in these frameworks. Thankfully, support for importing and exporting web components has improved in a lot of frameworks and you can almost use custom elements everywhere. But there are still aspects like style encapsulation that are a major footgun for majority adoption.
  2. Marketing problem from heavy-handed advocacy. Early on there was a lot of confusion between Web Components (the specs) and Polymer (the Google UI framework). Polymer was in a weird state for a long time: positioned as a competitor to other UI frameworks, even competed with Google’s other UI framework Angular, used a weird paper/iron/gold metaphor, required a polyfill, then Mozilla nuked HTML Imports… a shaky foundation to build on. Despite those real ergonomic and adoption concerns, some Google advocates engaged Twitter with a vibe of “React is shit and slow, you’re a dummy and a bad person if you use it, use web components instead” and… that strategy did not win hearts and minds. In that same timeframe, Google’s AMP (also made with web components) echoed the same talking points billing itself as a “bitter pill that the bloated mobile web had to swallow”. AMP is just one storyline in The Lost Decade of Web Development, but much has changed over the years. Lit solves a lot of problems/confusion that existed with Polymer and nowadays Web Components aren’t strictly “a Google thing”. Dozens and dozens of non-Google flavors of Web Components now exist like Stencil or Hybrids that are worth checking out.
  3. Hard to invest in something unknown. As an engineering manager it’s hard to advocate for re-platforming from React/Angular/Vue/Svelte to Web Components because there weren’t lots of case studies or popular products built with it. No website that says “blazing fast”. It’s not immediately clear what the advantages were and the intricacies of the Shadow DOM might, in fact, create more problems for your team. Now lots of companies are using web components to solve their problems. Despite these big companies adopting web components, there’s still a need for high quality case studies and blog posts.
  4. Not truly supported until very recently. Chrome in 2013, Safari in 2016, Firefox in 2018, and weren’t supported in Edge until 2020 when they switched to Chromium. If you used Web Components in production before 2020, you were using experimental tech. Today, support is much more broad. Safari and Firefox are a bit slower in supporting new standards, but some of the big gaps are now closed. Browser support coupled with a healthy diversity of libraries and new meta-frameworks like Rocket, Enhance, and Eleventy with WebC, there’s never been a better time to get started with Web Components.
  5. Web Components are slow. The last thing that’s held Web Components back is that they’re slow… slow, like brisket I like to say. Slow isn’t always a bad thing. Generally, they’re a stable foundation to build on but if you need a certain feature rolled out in every browser, you could potentially be waiting for a couple years for that fix to land. These are sometimes solveable in user-land, but with something like Cross-root ARIA, that’s a spec issue.

If I could turn back time…

If I could turn back time and get a redo on the whole Web Components rollout, I’d redo

  1. Make the ideal user persona a WordPress user instead of framework authors
  2. Establish the Web Components CG a lot earlier, make them less of “a Google thing”
  3. Make the styling story less confusing
  4. Establish a code of conduct at Google advocates
  5. Kill Firefox before they could kill HTML Imports

But that’s me. I’d love to know what you think Web Components’ big problems are and I can upstream that feedback to the Community Group.