Most active commenters
  • gavinray(4)
  • brundolf(4)

←back to thread

The Failed Promise of Web Components

(lea.verou.me)
367 points lemonberry | 14 comments | 30 Sep 20 15:59 UTC | HN request time: 1.268s | source | bottom
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 #
1. gavinray ◴[30 Sep 20 18:26 UTC] No.24641919[source]▶
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 into Web Components for publishing and consuming. (Preact does though, they put a lot of work into it).

Svelte, Vue, and (I believe) Angular can all emit web components.

In Vue, you can use the framework's standard data-binding and event capture syntax to interact with custom web components. You wouldn't be able to tell the difference between a Vue component and a Web Component you imported from a package.

(I can't speak for Angular, maybe someone could chime in here.)

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

It seems silly to write a wildly popular component/component-library, and vendor-lock it to a single framework. Why not just publish a web component version as well?

https://cli.vuejs.org/guide/build-targets.html#web-component

https://preactjs.com/guide/v10/web-components/

https://dev.to/silvio/how-to-create-a-web-components-in-svel...

https://angular.io/guide/elements

replies(2): >>24642072 #>>24642331 #
2. brundolf ◴[30 Sep 20 18:38 UTC] No.24642072[source]▶
> 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 a version of that widget that's built specifically for your framework, or even just building one yourself. The compatibility layer doesn't matter if nobody's going to use it.

> To be frank, I think in large part this is due to React

I'm not sure. I think React saw that the web components model was broken and didn't waste the effort trying to stick to it, and built their own separate React world that wasn't broken and that's why they've been so successful. It's a shame and an indictment of the web platform, but I think from their perspective it was the right decision.

The real shame would be if React's mindshare is the thing now holding us back from finally solving this at a platform level. I can only speculate about that, but it doesn't seem out of the question.

replies(3): >>24642132 #>>24642185 #>>24642472 #
3. spankalee ◴[30 Sep 20 18:43 UTC] No.24642132[source]▶
> That means your app will take twice as long to load

Preact is like 3k minzipped. Just loading it will not make your app take twice as long to load.

replies(1): >>24642208 #
4. jchw ◴[30 Sep 20 18:47 UTC] No.24642185[source]▶
The webcomponents supporters seem hell bent on placing the blame somewhere other than webcomponents themselves. In the “truckload of dependencies” they fail to ask why those dependencies are really there, and in that required JS they fail to ask why its really needed. The webcomponents model isn’t just broken, its thoroughly broken, and I actually hold the opinion that it was never even a good idea, because it’s simply the wrong abstraction layer to be extending on.
replies(3): >>24642292 #>>24644116 #>>24655733 #
5. brundolf ◴[30 Sep 20 18:49 UTC] No.24642208{3}[source]▶
Preact is one of the very smallest frameworks. A full-fledged Vue bundle is ten times that size, and Angular is another 2x Vue's size. When I said "twice as long" I meant on average: taking some framework X and adding another framework Y.
6. brundolf ◴[30 Sep 20 18:54 UTC] No.24642292{3}[source]▶
> In the “truckload of dependencies” they fail to ask why those dependencies are really there, and in that required JS they fail to ask why its really needed

Yes, this is what I meant when I said the post is too snarky, but I don't think it's fair to take that as representative of all "webcomponents supporters". That JS exists to fill a gap left by the platform, and it's a gap that should be filled by the platform, but it's also a gap that isn't filled by the platform.

> I actually hold the opinion that it was never even a good idea, because it’s simply the wrong abstraction layer to be extending on

I disagree. HTML is a profoundly intuitive and accessible standard which reaches far outside the normal bounds of software developers. This is evidenced by the thriving diversity the web has experienced (before everything moved to closed platforms, that is). For static content it already provides an exceptional balance between expressiveness and accessibility, and the dream of web components was to bring that over to apps as well. And I really do think that idea is still a good one.

7. k__ ◴[30 Sep 20 18:58 UTC] No.24642331[source]▶
"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...

replies(1): >>24642427 #
8. gavinray ◴[30 Sep 20 19:05 UTC] No.24642427[source]▶
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.

9. gavinray ◴[30 Sep 20 19:09 UTC] No.24642472[source]▶
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.

replies(1): >>24642676 #
10. lowkeyokay ◴[30 Sep 20 19:26 UTC] No.24642676{3}[source]▶
StencilJS does this too. It also has a wrapper to create React components. I really recommend it
replies(1): >>24642784 #
11. gavinray ◴[30 Sep 20 19:34 UTC] No.24642784{4}[source]▶
I completely forgot about Stencil from the Ionic team.

Definitely agreed. If you want an example of Web Components working cross-framework, look at Ionic and Stencil tbh.

12. isochronous ◴[30 Sep 20 21:28 UTC] No.24644116{3}[source]▶
I mean, we're using web components to build large web apps at my workplace, and in my experience 95% of the dependencies of web components are... other web components. Which makes sense for anything more complex than a simple button. The whole point of web components is to create portable, reusable code that can be encapsulated within an HTML tag, so if I'm writing an app that needs buttons, inputs, date pickers, etc, obviously I'm going to import components for those things where native controls don't meet my needs. I don't understand why "it has dependencies" is a valid criticism.
replies(1): >>24647018 #
13. hunterloftis ◴[01 Oct 20 03:27 UTC] No.24647018{4}[source]▶
> in my experience 95% of the dependencies of web components are... other web components

Sure, and in a single project at a single company that's probably fine. You've all agreed to standardize on a single version of Lit-Element and compile the whole project at once, so no worries.

But if the goal is to make Web Components standard units of UI across the web, such that you can grab a `color-picker` component and a `webcam-video` component and put them together into your `video-color-filter` component... well, if color-picker depends on vue and webcam-video depends on lit and you write video-color-filter in LWC, your project now depends on three web component libraries.

14. pjmlp ◴[01 Oct 20 20:17 UTC] No.24655733{3}[source]▶
Given that React is the exception in regards to WebComponents support.....