←back to thread

The Failed Promise of Web Components

(lea.verou.me)
367 points lemonberry | 1 comments | 30 Sep 20 15:59 UTC | HN request time: 0.218s | source
Show context
brundolf ◴[30 Sep 20 18:17 UTC] No.24641794[source]▶
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.

replies(15): >>24641919 #>>24642450 #>>24642466 #>>24642483 #>>24642571 #>>24642817 #>>24643568 #>>24643650 #>>24645120 #>>24645518 #>>24645996 #>>24646536 #>>24646560 #>>24647542 #>>24647873 #
mightybyte ◴[30 Sep 20 19:09 UTC] No.24642483[source]▶
> Here's what killed web components: lack of native databinding on the web.

I tend to agree with this broad idea. Although I don't think it's because it was left out or someone didn't do it. I think it's because it's REALLY HARD™. This is certainly the problem that React/Vue/etc are trying to solve. But I think web components never lived up to the promise because as an industry we simply haven't solved that problem yet. OOP possibly came as close as we've come. The various JS frontend frameworks have also been a decent attempt, but I just don't think it's good enough yet.

If I had to guess I'd say that FRP, functional programming's take on it, has the best chance at succeeding here. But I don't think it's quite there yet either. And even if it was, you still also have to confront the fact that the HTML/CSS split doesn't completely live up to the goal of the style being completely independent from the markup.

replies(1): >>24642559 #
1. brundolf ◴[30 Sep 20 19:16 UTC] No.24642559[source]▶
The issue with taking a FRP approach for any native solution, is that it would be fairly at-odds with the web as it works now. In particular: I don't know how you'd do that within just HTML, without any JavaScript. The style used by the likes of Angular and Vue, on the other hand, would be a much more natural fit for the web platform, for better or worse.

> This is certainly the problem that React/Vue/etc are trying to solve. But I think web components never lived up to the promise because as an industry we simply haven't solved that problem yet...The various JS frontend frameworks have also been a decent attempt, but I just don't think it's good enough yet.

I think the territory has been thoroughly explored at this point, and simply taking one of the established approaches and implementing it in C++ would be the right way forward. Now, back when web components were really making waves the landscape was different. This new wave of reactive frameworks was still fairly immature, and maybe in hindsight that's why they didn't standardize databinding at that time: it wasn't yet obvious what to standardize on, exactly. But I think in 2020 we're now past that point.