4 ms·

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 syst

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://cli.vuejs.org/guide/build-targets.html#web-component https://preactjs.com/guide/v10/web-components/ https://preactjs.com/guide/v10/web-components/ https://dev.to/silvio/how-to-create-a-web-components-in-svelte-2g4j https://dev.to/silvio/how-to-create-a-web-components-in-svel... https://angular.io/guide/elements https://angular.io/guide/elements

brundolf 6y ago
> 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.
- spankalee 6y ago
  > 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.
  - brundolf 6y ago
    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.
- jchw 6y ago
  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.
  - brundolf 6y ago
    > 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.
k__ 6y ago
"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...
- gavinray 6y ago
  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.

brundolf 6y ago

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

spankalee 6y ago
> 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.
- brundolf 6y ago
  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.
jchw 6y ago
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.
- brundolf 6y ago
  > 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.

k__ 6y ago

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

gavinray 6y ago
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.