Unfulfilled hopes of web components

Web Components promised so many new possibilities for HTML, with them web development should have become much more accessible for non-programmers and easier for programmers. Remember the thrill of every new HTML element that actually did something? Remember how great it was when it became possible to make sliders, color pickers, dialog boxes, drop-down widgets right in HTML, without having to include any libraries?

HTML LEARNING
HTML LEARNING

 

Web Components were expected to provide the same usability, but for a much wider range of HTML elements, and much faster because no one would have to wait for the entire standardization and implementation cycle. Just plug in the script, and bam – we have even more elements at our disposal!

At least that’s how it was intended. At some point, the space was flooded with JS framework fanatics, crazy about complex APIs, clever build processes and dependency graphs, similar to the roots of a banyan tree.

This is what the roots of the banyan tree look like. Photo by David Stanley on Flickr (CC-BY license).

Viewing the component code on webcomponents.org makes me shudder, but for me writing JS is the most common thing – I make money with it! What hope is there for those who can’t write JS? To use a custom item from the catalog, you often first have to do a whole ritual like npm flugelhorn, import clownskiets, build chtootam – all this without explanation, just because “here’s my bunch of dependencies, yeah, that’s all.” Many steps are skipped, apparently as “obvious”. And often you wade through this maze only to find out that a component no longer works or is not suitable for your task.

In addition to the complexities of installation, the main problem with the design of these components is that they do not pay enough attention to HTML. They are not designed to be as close as possible to standard HTML elements, but rather rely on writing JS to get them to do something useful. HTML is viewed as just a shorthand, or worse, purely as a marker of the place of the future element in the DOM, and all parameters are passed through JS. I recall Jeremy Keith’s excellent talk on this phenomenon a few years ago, where he looked at this example of a Google Store Web Component, a prime example of this approach. Here’s the entire content 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 Google itself provides such an example, then how can we hope that components from other authors will adhere to generally accepted HTML conventions?

Jeremy criticized this approach in terms of backward compatibility: if JS fails to load or is disabled, or the browser does not support web components, there will be a blank page instead of the entire site. While this is really a serious remark, for me convenience comes first: HTML is a language with a low entry threshold. Many more people can write HTML than JS. Even those who eventually start writing JS often come to this after years of working with HTML and CSS.

If the components are made in such a way that they cannot without JS, then this closes them for thousands of potential users. And even for those who know how to write JS, it is often easier to deal with HTML: not so many people use JS sliders or sculpt their own when <input type = “range”> is supported everywhere, right?

Even when JavaScript is essential, there are many shades between the extremes. A well-designed HTML element can keep the amount and complexity of JS required to a minimum. Take the <dialog> element: it usually requires * a little * JS, but most of the time the code is pretty simple. Likewise, the <video> element is fully functional if you just write it in HTML, and has a clear JS API for anyone who wants to do something cool.

Once again, I was looking for a simple, no dependency, tab component. You know, this is a classic example of something that can be easily done in web components that is mentioned in half of the tutorials. I didn’t even care what it looked like, I needed it to test the interface. I wanted something small that would work like a normal HTML element. It was so difficult to find it that I had to write my own!

Can this be fixed?
I’m not sure if this is a problem with the web components themselves or their documentation. There are probably easier ways to use many of these web components. Perhaps there are “vanilla” web components out there that I just didn’t find. Perhaps I’m looking in the wrong place, and somewhere there is another directory with different tasks and a different target audience.