7 ms·

I think this minimizes the fact that interop - the main selling point to me as a user - comes at a performance cost where every component you use could have its

I think this minimizes the fact that interop - the main selling point to me as a user - comes at a performance cost where every component you use could have its own unnecessary runtime attached.[1] Using a framework like Lit with web components is the recommended way to use them. This cost will compound over time where new frameworks emerge, and components get stuck on older versions of their frameworks. I can't see this as anything but significant, and not to be minimized. Having multiple redundant libraries on a page is not the direction I would advise anyone to take, particularly not when baked into the accepted best practices. This bodes poorly in the long term. I've listened to the arguments from web component advocates in blog posts, social media, and videos for years now, and I should be in the target market. But on top of the interop tax, they're full of negatives that aren't present in the mainstream frameworks. Interop works great within each framework's ecosystem. The same dynamics that cause developers to seek interop cause them to huddle around a small number of mainstream frameworks. So we get a few vibrant ecosystems that push the state of the art together. Web components cannot keep up on the tech side of things, and introduce a ton of complexity to the web platform - ignorable to me as a dev, but not for browser implementers - in service of their early 2010s designs. [1] https://x.com/Rich_Harris/status/1840116730716119356 https://x.com/Rich_Harris/status/1840116730716119356

afavour 2y ago
While this is true I think the multiple libraries problem is a rounding error when you look at the majority of web apps created today. React and react-dom combined are over 100KB. Svelte and Lit are in the single digits. So you could embed a lot of frameworks before you get close to the bloat people use every single day without even thinking about it.
- webdevladder 2y ago
  As a Svelte user this argument rings hollow. You can't judge frontend by React and the way it's badly used.
  - afavour 2y ago
    > You can't judge frontend by React and the way it's badly used. IMO you can because it’s the vast majority of webapp usage today. I’m also a heavy Svelte user and I love it but front end web dev is practically a React monoculture so it makes sense to think about it when evaluating options. I’m not saying it isn’t a problem inherent in web components, it is. But using it as a reason to not adopt web components runs contrary to the logic the vast majority of the industry currently uses. Perfect as the enemy of good and all that.
    - webdevladder 2y ago
      React is irrelevant for me and my users. This is not an argument in favor of web components over Svelte. Adopting web components would mean an objectively worse UX for my users - for example requiring them to enable JS. You won't get a Svelte to look past the flaws of web components by saying "React is bad".
      - afavour 2y ago
        Yes, you’re talking about you and your users. I’m talking about the industry at large. Those two perspectives don’t have to line up. The article we’re discussing is titled “Web Components are okay”, not “Web Components are better than Svelte for webdevladder and their users”.
        webdevladder 2y ago
        Look at the thread you've created here - I'm arguing that the article minimizes the antipattern cost they impose, and your response brings up React as if it somehow changes that.
        afavour 2y ago
        Yes, I previously mentioned the “perfect as the enemy of good” argument. Like I already said, I use and like Svelte. But the vast majority of the web dev ecosystem uses React. Web components would be better than everyone using React. Arguably everyone using Svelte could be better still but that’s a separate debate. > your response brings up React as if it somehow changes that. It does. Because the industry clearly has no problem with a large upfront cost, given that it imposes one today. Web components would be better than what we have today even if it isn’t the ideal.
- hajile 2y ago
  React has one up-front size for rendering code whether you use 1 component or 10,000 components. Svelte and Lit rendering code size just keeps going up, and up, and up.... You can argue about which is better, but this kind of naive size comparison is disingenuous.
  - afavour 2y ago
    While it’s true that Svelte and Lit can grow in size dependent on project there’s no world in which even large projects get close to the base level of the React runtime.
    - troupo 2y ago
      Reddit rewrote a small part of their website with web components using lit. 100+ requests and over a megabyte of Javascript to render a side menu. Because they probably did the "several runtimes don't matter" thing, and every tiny component loads the full lit runtime
      - spankalee 2y ago
        > every tiny component loads the full lit runtime This is just not true.
        troupo 2y ago
        Why does it need 100+ requests and over a megabyte of JS then? Edit: when it was "unveiled" the sum total of JS was 178 requests totaling 1.37 MB: https://x.com/dmitriid/status/1777404560316707052 https://x.com/dmitriid/status/1777404560316707052
        spankalee 2y ago
        I don't know, but it only loads one copy of Lit.
        2y ago
skrebbel 2y ago
I don't really understand this argument, to be frank. Most runtimes are pretty small, and there's not much of a performance overhead to both runtimes running at the same time. It's not like these are two realtime engines both purring along in the background or something like that. All modern web frameworks are reactive, and won't do anything unless something needs responding to. If one part of the page is built with React, another part is built with Lit, and a third part with Svelte, I don't see how that will have noticeably worse UX (or battery consumption) than a page made with just one framework, even when reactive triggers are frequently exchanged between them. The tweet you quote is about whether web components are "useful primitives on which to build frameworks". I doubt many web component fans (who actually really used them) would say that they are. They're a distribution mechanism, and the only alternative I've seen from these framework authors is "just make the same library 7 times, once for React, once for Preact, once for Svelte, once for Solid, once for Vue, once for vanilla JS". This is awful.
- webdevladder 2y ago
  You're ignoring page bloat as a performance cost. That's hugely impactful for UX on the web.
  - skrebbel 2y ago
    Not entirely, I said "Most runtimes are pretty small". I think people got trained by React into thinking that frameworks are big. SolidJS is 7kb, Lit is 5kb, Svelte is tiny and used to have no runtime at all, etc. Only React is big. And, well, if you're writing React components and publishing them as web components, it's usually quite feasible to build them with Preact instead, which is tiny as well. So on a page with like some hodgepodge of 5 frameworks purring along inside various web components, there's still going to be only 20-30 kb of extra overhead. You can compress one image slightly better and save more than that.
    - webdevladder 2y ago
      The point being made is that web components can pay this cost per-component, and this problem will compound over time. This is an unprecendented cost to frontend framworks and it's the expected usage pattern.
nolanl 2y ago
I cover this in another post [1], but broadly: - Not every web app is perf-sensitive to every extra kB (eCommerce is, productivity tools typically aren't) - Plenty of frameworks have tiny runtimes, e.g. Svelte is 2.7kB [2] - I wouldn't advocate for 100 different frameworks on the page, but let's say 5-6 would be fine IMO No one is arguing that this is ideal, but sometimes this model can help, e.g. for gradual migrations or micro-frontends. BTW React 17 actually introduced a feature where you could do exactly this: have multiple versions of React on the same page [3]. [1]: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/ https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp... [2]: https://bundlephobia.com/package/svelte@4.2.19 https://bundlephobia.com/package/svelte@4.2.19 [3]: https://legacy.reactjs.org/blog/2020/10/20/react-v17.html https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
webdevladder 2y ago
A more broad observation, I'm being pointed in the parent comment - web components need to win over framework authors. The signs are not trending well here from what I've seen consistently. That community is on X and web components are not addressing their problems and they're not used in optimal scenarios. I hope web components can win them over but they're mostly saying they've been a failure, arguably on balance bad for the web.

afavour 2y ago

While this is true I think the multiple libraries problem is a rounding error when you look at the majority of web apps created today. React and react-dom combined are over 100KB. Svelte and Lit are in the single digits. So you could embed a lot of frameworks before you get close to the bloat people use every single day without even thinking about it.

webdevladder 2y ago
As a Svelte user this argument rings hollow. You can't judge frontend by React and the way it's badly used.
- afavour 2y ago
  > You can't judge frontend by React and the way it's badly used. IMO you can because it’s the vast majority of webapp usage today. I’m also a heavy Svelte user and I love it but front end web dev is practically a React monoculture so it makes sense to think about it when evaluating options. I’m not saying it isn’t a problem inherent in web components, it is. But using it as a reason to not adopt web components runs contrary to the logic the vast majority of the industry currently uses. Perfect as the enemy of good and all that.
  - webdevladder 2y ago
    React is irrelevant for me and my users. This is not an argument in favor of web components over Svelte. Adopting web components would mean an objectively worse UX for my users - for example requiring them to enable JS. You won't get a Svelte to look past the flaws of web components by saying "React is bad".
    - afavour 2y ago
      Yes, you’re talking about you and your users. I’m talking about the industry at large. Those two perspectives don’t have to line up. The article we’re discussing is titled “Web Components are okay”, not “Web Components are better than Svelte for webdevladder and their users”.
      - webdevladder 2y ago
        Look at the thread you've created here - I'm arguing that the article minimizes the antipattern cost they impose, and your response brings up React as if it somehow changes that.
        afavour 2y ago
        Yes, I previously mentioned the “perfect as the enemy of good” argument. Like I already said, I use and like Svelte. But the vast majority of the web dev ecosystem uses React. Web components would be better than everyone using React. Arguably everyone using Svelte could be better still but that’s a separate debate. > your response brings up React as if it somehow changes that. It does. Because the industry clearly has no problem with a large upfront cost, given that it imposes one today. Web components would be better than what we have today even if it isn’t the ideal.
hajile 2y ago
React has one up-front size for rendering code whether you use 1 component or 10,000 components. Svelte and Lit rendering code size just keeps going up, and up, and up.... You can argue about which is better, but this kind of naive size comparison is disingenuous.
- afavour 2y ago
  While it’s true that Svelte and Lit can grow in size dependent on project there’s no world in which even large projects get close to the base level of the React runtime.
  - troupo 2y ago
    Reddit rewrote a small part of their website with web components using lit. 100+ requests and over a megabyte of Javascript to render a side menu. Because they probably did the "several runtimes don't matter" thing, and every tiny component loads the full lit runtime
    - spankalee 2y ago
      > every tiny component loads the full lit runtime This is just not true.
      - troupo 2y ago
        Why does it need 100+ requests and over a megabyte of JS then? Edit: when it was "unveiled" the sum total of JS was 178 requests totaling 1.37 MB: https://x.com/dmitriid/status/1777404560316707052 https://x.com/dmitriid/status/1777404560316707052
        spankalee 2y ago
        I don't know, but it only loads one copy of Lit.
        2y ago

skrebbel 2y ago

I don't really understand this argument, to be frank. Most runtimes are pretty small, and there's not much of a performance overhead to both runtimes running at the same time. It's not like these are two realtime engines both purring along in the background or something like that. All modern web frameworks are reactive, and won't do anything unless something needs responding to. If one part of the page is built with React, another part is built with Lit, and a third part with Svelte, I don't see how that will have noticeably worse UX (or battery consumption) than a page made with just one framework, even when reactive triggers are frequently exchanged between them. The tweet you quote is about whether web components are "useful primitives on which to build frameworks". I doubt many web component fans (who actually really used them) would say that they are. They're a distribution mechanism, and the only alternative I've seen from these framework authors is "just make the same library 7 times, once for React, once for Preact, once for Svelte, once for Solid, once for Vue, once for vanilla JS". This is awful.

webdevladder 2y ago
You're ignoring page bloat as a performance cost. That's hugely impactful for UX on the web.
- skrebbel 2y ago
  Not entirely, I said "Most runtimes are pretty small". I think people got trained by React into thinking that frameworks are big. SolidJS is 7kb, Lit is 5kb, Svelte is tiny and used to have no runtime at all, etc. Only React is big. And, well, if you're writing React components and publishing them as web components, it's usually quite feasible to build them with Preact instead, which is tiny as well. So on a page with like some hodgepodge of 5 frameworks purring along inside various web components, there's still going to be only 20-30 kb of extra overhead. You can compress one image slightly better and save more than that.
  - webdevladder 2y ago
    The point being made is that web components can pay this cost per-component, and this problem will compound over time. This is an unprecendented cost to frontend framworks and it's the expected usage pattern.

nolanl 2y ago

I cover this in another post [1], but broadly: - Not every web app is perf-sensitive to every extra kB (eCommerce is, productivity tools typically aren't) - Plenty of frameworks have tiny runtimes, e.g. Svelte is 2.7kB [2] - I wouldn't advocate for 100 different frameworks on the page, but let's say 5-6 would be fine IMO No one is arguing that this is ideal, but sometimes this model can help, e.g. for gradual migrations or micro-frontends. BTW React 17 actually introduced a feature where you could do exactly this: have multiple versions of React on the same page [3]. [1]: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/ https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp... [2]: https://bundlephobia.com/package/svelte@4.2.19 https://bundlephobia.com/package/svelte@4.2.19 [3]: https://legacy.reactjs.org/blog/2020/10/20/react-v17.html https://legacy.reactjs.org/blog/2020/10/20/react-v17.html

webdevladder 2y ago

A more broad observation, I'm being pointed in the parent comment - web components need to win over framework authors. The signs are not trending well here from what I've seen consistently. That community is on X and web components are not addressing their problems and they're not used in optimal scenarios. I hope web components can win them over but they're mostly saying they've been a failure, arguably on balance bad for the web.