The failed promise of Web Components
Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers. Remember how exciting it was every time we got new shiny HTML elements that actually do stuff? Remember how exciting it was to be able to do sliders, color pickers, dialogs, disclosure widgets straight in the HTML, without having to include any widget libraries?
The promise of Web Components was that weād get this convenience, but for a much wider range of HTML elements, developed much faster, as nobody needs to wait for the full spec + implementation process. Weād just include a script, and boom, we have more elements at our disposal!
Or, that was the idea. Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.
This is what the roots of a Banyan tree look like. Photo by David Stanley on Flickr (CC-BY).
Perusing the components on webcomponents.org fills me with anxiety, and Iām perfectly comfortable writing JS ā I write JS for a living! What hope do those who canāt write JS have? Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because āhere is my truckload of dependencies, yeah, whatā. Many steps are even omitted, likely because they are āobviousā. Often, you wade through the maze only to find the component doesnāt work anymore, or is not fit for your purpose.
Besides setup, the main problem is that HTML is not treated with the appropriate respect in the design of these components. They are not designed as closely as possible to standard HTML elements, but expect JS to be written for them to do anything. HTML is simply treated as a shorthand, or worse, as merely a marker to indicate where the element goes in the DOM, with all parameters passed in via JS. I recall a wonderful talk by Jeremy Keith a few years ago about this very phenomenon, where he discussed this e-shop Web components demo by Google, which is the poster child of this practice. These are the entire contents of its <body> element:
<body>
<shop-app unresolved="">SHOP</shop-app>
<script src="node_assets/@webcomponents/webcomponentsjs/webcomponents-loader.js"></script>
<script type="module" src="src/shop-app.js"></script>
<script>window.performance&&performance.mark&&performance.mark("index.html");</script>
</body>
If this is how Google is leading the way, how can we hope for contributors to design components that follow established HTML conventions?
Jeremy criticized this practice from the aspect of backwards compatibility: when JS is broken or not enabled, or the browser doesnāt support Web Components, the entire website is blank. While this is indeed a serious concern, my primary concern is one of usability: HTML is a lower barrier to entry language. Far more people can write HTML than JS. Even for those who do eventually write JS, it often comes after spending years writing HTML & CSS.
If components are designed in a way that requires JS, this excludes thousands of people from using them. And even for those who can write JS, HTML is often easier: you donāt see many people rolling their own sliders or using JS-based ones once <input type="range"> became widely supported, right?
Even when JS is unavoidable, itās not black and white. A well designed HTML element can reduce the amount and complexity of JS needed to a minimum. Think of the <dialog> element: it usually does require *some* JS, but itās usually rather simple JS. Similarly, the <video> element is perfectly usable just by writing HTML, and has a comprehensive JS API for anyone who wants to do fancy custom things.
The other day I was looking for a simple, dependency free, tabs component. You know, the canonical example of something that is easy to do with Web Components, the example 50% of tutorials mention. I didnāt even care what it looked like, it was for a testing interface. I just wanted something that is small and works like a normal HTML element. Yet, it proved so hard I ended up writing my own!
Can we fix this?
Iām not sure if this is a design issue, or a documentation issue. Perhaps for many of these web components, there are easier ways to use them. Perhaps there are vanilla web components out there that I just canāt find. Perhaps Iām looking in the wrong place and there is another directory somewhere with different goals and a different target audience.
But if not, and if Iām not alone in feeling this way, we need a directory of web components with strict inclusion criteria:
- Plug and play. No dependencies, no setup beyond including one
<script>tag. If a dependency is absolutely needed (e.g. in a map component it doesnāt make sense to draw your own maps), the component loads it automatically if itās not already loaded. - Syntax and API follows conventions established by built-in HTML elements and anything that can be done without the component user writing JS, is doable without JS, per the W3C principle of least power.
- Accessible by default via sensible ARIA defaults, just like normal HTML elements.
- Themable via
::part(), selective inheritance and custom properties. Very minimal style by default. Normal CSS properties should just āworkā to the the extent possible. - Only one component of a given type in the directory, that is flexible and extensible and continuously iterated on and improved by the community. Not 30 different sliders and 15 different tabs that users have to wade through. No branding, no silos of ācomponent librariesā. Only elements that are designed as closely as possible to what a browser would implement in every way the current technology allows.
I would be up for working on this if others feel the same way, since that is not a project for one person to tackle. Whoās with me?
UPDATE: Wow this post blew up! Thank you all for your interest in participating in a potential future effort. Iām currently talking to stakeholders of some of the existing efforts to see if there are any potential collaborations before I go off and create a new one. Follow me on Twitter to hear about the outcome!