Live data from Hacker News

The Failed Promise of Web Components

lea.verou.me

51–60 of 235 posts

Re: The Failed Promise of Web Components

#52

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 i…

To be frank, I think in large part this is due to React. I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this). React also doesn't have an easy means of turning React components int…

"To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard."

How does "blaming the customer" help here?

It's not the first time that a standard doesn't fit the people it was created for...

Re: The Failed Promise of Web Components

#54
post #52

Earlier quoted context omitted.

To be frank, I think in large part this is due to React. I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this). React also doesn't have an easy means of turning React components int…

"To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard." How does "blaming the customer" help here? It's not the first time that a standard doesn't fit the people it was created for...

Didn't mean to come off that way if I did -- I'm not trying to point fingers or put blame on anyone. But the fact that as a community, the ecosystem is fractured between major frameworks and there's not a solid interoperable standard is a bit sad.

Everyone is worse off for it. It may be that a spec/implementation does not exist which can satisfy these needs but it would be beneficial for all.

Re: The Failed Promise of Web Components

#55

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 i…

We had XUL at one stage which is I think what you’re talking about. It just never took off. I think you’re pointing out that the premise itself is flawed given the clunky nature of html, which could be why ...

Re: The Failed Promise of Web Components

#56

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 i…

Related to this, it annoys me that Polymer is sometimes described as not a framework, as if it's just a set of polyfills/shims.

Of course it's a framework, it provides a data-binding system that is incompatible with other frameworks, and which isn't simply a polyfill.

Re: The Failed Promise of Web Components

#57

Earlier quoted context omitted.

To be frank, I think in large part this is due to React. I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this). React also doesn't have an easy means of turning React components int…

> To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard The problem is that if you're writing a Vue app, and you import a web component that was written in Preact, you're now loading both Vue and Preact onto your page. That means your app will take twice as long to load. That is a huge downside to weigh against the inconvenience of having to find…

The point about the shipping the framework as a dependency is a good one. In the grand scheme of things it's not the end of the world but shipping multiple framework runtimes is definitely not ideal.

Svelte is the outlier here, where the end-product is fully compiled to standard API's without a runtime. Maybe we'll see more frameworks adopt this approach in the future.

Re: The Failed Promise of Web Components

#58

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 i…

> 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.

Re: The Failed Promise of Web Components

#59
post #37

Earlier quoted context omitted.

> Pulling a menu out from the left certainly cannot be implemented on iOS Safari Mobile Well HTML5 apps will never be a good experience on iOS then. On Android you can do almost anything UI-wise with Chrome, which paves the way to HTML5 installable apps.

My hot take: hamburger menus are a really bad UX paradigm in almost all cases, and bottom tab bars are much better. So, I disagree entirely: iOS can easily support fantastic HTML5 mobile apps... if push notifications ever become available. From what I remember, Google started switching to bottom tab bars a couple of years ago, even on Android. But, when you have a bunch of features, it's much easier on the developer…

> bottom tab bars are much better

The last time I looked they were incredibly fragile to implement on mobile device browsers. Mobile Safari had borkage: rotation or tab addition/deletion changing the page height such that you occasionally lose the bottom bar; input focus loses the bottom bar or leaves the bottom bar occluding elements (position sticky doesn’t recalc when page scrolls). Problems with strange interactions with the browsers own bottom bar. Both have problems when the page is zoomed, which seems to happen sometimes even if explicitly disabled e.g. input focus?

I could make something that looked like it worked, but when actually manually testing it hard, there were show-stopping problems.

Re: The Failed Promise of Web Components

#60

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 i…

> 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 y…

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.

Post reply on HN