←back to thread

367 points lemonberry | 1 comments | | HN request time: 0.208s | source
Show context
brundolf ◴[] 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 #
gavinray ◴[] 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 #
k__ ◴[] 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 #
1. gavinray ◴[] 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.