4 ms·

Put simply: if you’re using something like React, Vue, Svelte, whatever, then Web Components are strict overhead in terms of bundle size and runtime overhead. A

Put simply: if you’re using something like React, Vue, Svelte, whatever, then Web Components are strict overhead in terms of bundle size and runtime overhead. And when there’s impedance mismatch between the two worlds, which I hear is particularly common in React (can’t attest it personally, I don’t use React), you have to compromise on functionality or ergonomics, or else do fancier bindings, at which point why even bother with Web Components? It will also commonly not play nicely with some more advanced aspects of the frameworks, like server-side rendering will probably suffer (depending on how exactly things are done). In a world where React is dominant and you’re wanting to use React yourself, targeting Web Components just doesn’t make sense. Then “headless” makes it worse. The more comprehensive implementations have a lot of overhead.

combyn8tor 1y ago
Here's my put simply: We've got some UI components built with html, CSS and JavaScript. They use web standards. We want to add them into web frameworks that are built in JavaScript. They are built for html, CSS and JavaScript. No need to overcomplicate things. And for a universal component library I'll happily accept 7kb extra overhead in my 4mb React slop website
- sensanaty 1y ago
  But the data binding part isn't the same across frameworks. In Vue you have v-model, in React it's props and so on. The way you build a custom Select Dropdown, for example, will be very different between the two. Sure, the actual HTML/CSS parts will be identical, but the JS portion is the issue here, because frameworks simply handle things differently there. In Vue you have reactive proxies getting passed around and a custom event system, whereas in React it's all objects and methods passed around as props.
owebmaster 1y ago
> In a world where React is dominant and you’re wanting to use React yourself, targeting Web Components just doesn’t make sense. Just a reminder that jQuery was once dominant, too.

combyn8tor 1y ago

Here's my put simply: We've got some UI components built with html, CSS and JavaScript. They use web standards. We want to add them into web frameworks that are built in JavaScript. They are built for html, CSS and JavaScript. No need to overcomplicate things. And for a universal component library I'll happily accept 7kb extra overhead in my 4mb React slop website

sensanaty 1y ago
But the data binding part isn't the same across frameworks. In Vue you have v-model, in React it's props and so on. The way you build a custom Select Dropdown, for example, will be very different between the two. Sure, the actual HTML/CSS parts will be identical, but the JS portion is the issue here, because frameworks simply handle things differently there. In Vue you have reactive proxies getting passed around and a custom event system, whereas in React it's all objects and methods passed around as props.

owebmaster 1y ago

> In a world where React is dominant and you’re wanting to use React yourself, targeting Web Components just doesn’t make sense. Just a reminder that jQuery was once dominant, too.