The Failed Promise of Web Components

This post is needlessly snarky, but I don't disagree with the basic premise.

Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that instead of one large framework on the page you have five or six, all of them stitched together through rickety HTML-attribute APIs and custom value-parsing strategies because HTML attributes are just strings.

I fail to grasp why databinding hasn't made it into a web standard yet. The web has a long tradition of feeling out features in the JS world before adopting the successful ones into the platform. jQuery turned into querySelector() and fetch(), CommonJS modules blazed the trail that led to ES modules, etc. And this next paradigm is more than ready to get standardized. Not only would it make the dream of web components possible, it would eliminate the need for a whole lot of the JavaScript out there and even make UIs faster, since reactivity logic would be implemented natively.

It's such an obvious, ubiquitous improvement to the web that I can only assume there's some fundamental implementation roadblock I'm missing.

I'm a strong proponent of separation of duties on the web (style and visuals in CSS, layout in HTML, anything interactive in JS). Enabling data binding in HTML would only serve to blur those lines.

With some minimal JS, you can update each web component already. Is writing nameField.innerText = response.name really that difficult? What problem does it solve to make a standard for it? As for (de)serialization, JS has built-in support for JSON and XML. HTML attributes are everything but rickety in my opinion, as any decent parser will allow you to access them as if they are a normal dictionary. Put JSON in them if you really want to encode complex data in attributes, although you probably shouldn't.

I strongly believe the abhorrent overuse of React and other such libraries on the web is the sole reason our computers have gotten hundreds of times faster but the web is only slightly as quick. I don't see a place in web standards for a React-style functional design because of the specific rules each of these libraries have.

> I strongly believe the abhorrent overuse of React and other such libraries on the web is the sole reason our computers have gotten hundreds of times faster but the web is only slightly as quick.

If browsers provided data binding and reactivity out of the box, frameworks and applications would be much faster and lighter.

Web browsers provide many features out of the box but frameworks rarely use them. Web components are one thing; HTML templates are another. Streaming video is being decoded by Javascript even though every browser supports H.264, input elements such as calendar controls are rewritten, animations are done in JS instead of smooth CSS transitions, drag and drop support is manually rewritten in JS...

Whenever a feature gets added to standard HTML, web frameworks and "polyfills" keep implementing their own versions because the standards don't fit them and they don't want to rewrite (or keep their own implementation as a mere fallback).

Even if a data binding framework would be standardized today, it would take years for browsers to catch up and gain critical mass. There'd only be more polyfills and Javascript to help support people running IE11 or whatever.

I'm glad many JS features have been implemented natively in HTML5, but this specific case feels overkill to me. HTML templates have been introduced and then ignored by frameworks already and I doubt any framework would switch over to a new data binding API if it became a standard today.

> Streaming video is being decoded by Javascript even though every browser supports H.264

Maybe in some experimental project, but I've never seen this in any video site.

> input elements such as calendar controls are rewritten

Yes, because the native browser widgets are totally insufficient and can't be styled.

> animations are done in JS instead of smooth CSS transitions

JS animation can be super fast (see GSAP) and it seems you're talking about jQuery.animate() which I agree was terrible. But these days most people use CSS animations.

> drag and drop support is manually rewritten in JS

Again, because the browser does not have a proper drag and drop API to do it. I know because I've had to implement drag and drop many times. From vanilla, to jQuery, to React... for mouse and touch UIs.

Here's another huge thing lacking in the browser world: touch gestures.