Custom Elements Everywhere

published on 2023/08/03
Web

Custom Elements are the lynchpin in the Web Components specifications. They give developers the ability to define their own HTML elements. When coupled with Shadow DOM, Custom Elements should be able to work in any application. But things don't always work seamlessly.

This project runs a suite of tests against each framework to identify interoperability issues, and highlight potential fixes already implemented in other frameworks. If frameworks agree on how they will communicate with Custom Elements, it makes developers' jobs easier; they can author their elements to meet these expectations.

Custom Elements Everywhere

I found this wonderful resource via this essay on why it took a long time for Web Component to be adopted

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.