7 ms·

It seems like Web Components are ideal for libraries shipping pre-built components, which is probably why Mux finds it compelling. From Mux's point of view, the

It seems like Web Components are ideal for libraries shipping pre-built components, which is probably why Mux finds it compelling. From Mux's point of view, they want the highest level of compatibility with the least amount of framework lock-in. For example, they don't want to have to ship a library for React and another one for Vue and another one for bare bones JS/HTML. In terms of building a web app where you control the environment end-to-end, I don't think there's any inherent upside to using Web Components over React.

dylanjha 2y ago
(author from Mux here) -- that is correct. For the stuff we build for in-house use on mux.com and dashboard.mux.com we have a components library written in React. You nailed it that we are shipping SDKs with visual components (like a video player) that need to be compatible across all kinds of frontends. Instead of N number of SDKs to maintain where N is every front end framework, we have 2: a web component, and a React wrapper around the web component. Maybe in the (near) future we only have to maintain 1.
spartanatreyu 2y ago
> I don't think there's any inherent upside to using Web Components over React. The upside is that web components will last longer than react components. There was a great blog post about this very thing and why someone chose them over react components in their use case (making their code migration-proof across updates and stack changes): https://jakelazaroff.com/words/web-components-will-outlive-your-javascript-framework/ https://jakelazaroff.com/words/web-components-will-outlive-y...
- wokwokwok 2y ago
  They won't last longer than a react component (that's not even the claim the linked post is making); you can just use them in a different framework, if you care about that. ...which is the point the parent comment was making.
  - djbusby 2y ago
    I read the point as WebComponents will last longer because "a standard" while React is "a Facebook standard".
    - hn_throwaway_99 2y ago
      There's also the "React is the industry standard that tons of developers and companies use" vs. the "WebComponents is the 'official' standard that nearly nobody uses". Yes, I'm being hyperbolic. But if you're worried about longevity I would certainly hitch my wagon to React before I hitched it to WebComponents.
      - croes 2y ago
        React is like JQuery.
        Dylan16807 2y ago
        If it's a choice between removing the JQuery dependency from old JQuery code, or updating equally old vanilla javascript, I'm going to be picking the first option a lot.
        afavour 2y ago
        Unfortunately I don’t think that comparison quite holds. jQuery is mentioned less and less because core browser APIs implemented a lot of what it does and made it unnecessary. Even if Web Components solve the “create a component” part of React there’s still an absolute ton of stuff it provides that Web Components don’t. I tend to think of WC as a low level API you want a library interfacing with rather than your own code, e.g. the way Svelte exports web components.
    - sdwr 2y ago
      The point isn't that it's a standard, it's that it's implemented in browser (not in a framework), and is a lot closer to the web equivalent of "bare metal". There are less moving pieces that will break backwards compatibility in the next 10 years (is the hope)
- lmm 2y ago
  > The upside is that web components will last longer than react components. How much are you betting? React components have been around longer and are more widely established, so personally I'd expect them to last longer.
  - spartanatreyu 2y ago
    > How much are you betting? If you're prepared to put money down on it, I'd wager $500USD on longbets that Web Components will still function in 20 years. And I'd wager another $500USD on longbets that it will be easier to port a web component written in 2024 into a new project written in 2044 than it will be to port a react component written in 2024 into a new project written in 2044. The reason why I'm so confident is that Web Components are already a standard.
    - sieabahlpark 2y ago
      [dead]
    - stickfigure 2y ago
      I am not a betting man, but I would not be so sure. The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet. As someone who has been doing GUI development since 16-bit Windows, it's really remarkable to me how much staying power React has. It's 10 years old and still the dominant way of building web applications. I can't think of any other frontend library (web or native) that has had that long of a run at the head of the pack. What I'd be most concerned about with any 20-year bet is what new paradigm/library might come along and supplant the old ways. Standard or not, React has a critical mass that will keep it viable even if it becomes "legacy". If some new hotness makes web components look old-fashioned, the small community could disappear pretty fast - browser standard or no. Ask any XSLT developer.
      - spartanatreyu 2y ago
        > The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet. Web Components are used by internally by browsers to implement elements. As dannye stated (https://news.ycombinator.com/item?id=40292970 https://news.ycombinator.com/item?id=40292970): input, textarea and video are all web components. And since the major browsers have implemented those elements in that fashion I think it's safe to say they have most certainly reached widespread adoption. (even if most people haven't realized yet) > I can't think of any other frontend library (web or native) that has had that long of a run at the head of the pack. Flash and jQuery come to the front of my mind. React (or at least the React of today) will one day be looked back just as we look back at what came before it. I think it'd probably be fair to say we're at that point about 10 years after the record-tuple proposal goes through and the explicit resource management gets a syntactic sugar upgrade a la promises to async/await. They shift the paradigm enough that the old assumptions used when building our current frameworks will need to be re-examined. New frameworks will be able to blossom, and/or the current frameworks will shift enough internally that they won't resemble how they are today, and they will have to drop support for older code, or run slower compatibility layers that no one would want to use on newer projects. Even if one of those proposals fails to go through, we would still have other standards moving with enough momentum to eventually change the landscape. In the long term, I'm looking at a lot of capabilities being added to wasm to make compile-to-wasm look more attractive.
- danielrhodes 2y ago
  Your quote omits the qualifying part of that sentence, which is important. :-) What does it mean to "last longer" when it comes to your own codebase? And why would web components help with that?
  - spartanatreyu 2y ago
    The linked blog post goes through that.
pier25 2y ago
> I don't think there's any inherent upside to using Web Components over React. What about using web components in a server rendered application without needing to resort to running JavaScript in the server?
junon 2y ago
Yep, pretty much. They're a pain to develop for but worth it if you're writing libraries.

dylanjha 2y ago

(author from Mux here) -- that is correct. For the stuff we build for in-house use on mux.com and dashboard.mux.com we have a components library written in React. You nailed it that we are shipping SDKs with visual components (like a video player) that need to be compatible across all kinds of frontends. Instead of N number of SDKs to maintain where N is every front end framework, we have 2: a web component, and a React wrapper around the web component. Maybe in the (near) future we only have to maintain 1.

spartanatreyu 2y ago

> I don't think there's any inherent upside to using Web Components over React. The upside is that web components will last longer than react components. There was a great blog post about this very thing and why someone chose them over react components in their use case (making their code migration-proof across updates and stack changes): https://jakelazaroff.com/words/web-components-will-outlive-your-javascript-framework/ https://jakelazaroff.com/words/web-components-will-outlive-y...

wokwokwok 2y ago
They won't last longer than a react component (that's not even the claim the linked post is making); you can just use them in a different framework, if you care about that. ...which is the point the parent comment was making.
- djbusby 2y ago
  I read the point as WebComponents will last longer because "a standard" while React is "a Facebook standard".
  - hn_throwaway_99 2y ago
    There's also the "React is the industry standard that tons of developers and companies use" vs. the "WebComponents is the 'official' standard that nearly nobody uses". Yes, I'm being hyperbolic. But if you're worried about longevity I would certainly hitch my wagon to React before I hitched it to WebComponents.
    - croes 2y ago
      React is like JQuery.
      - Dylan16807 2y ago
        If it's a choice between removing the JQuery dependency from old JQuery code, or updating equally old vanilla javascript, I'm going to be picking the first option a lot.
      - afavour 2y ago
        Unfortunately I don’t think that comparison quite holds. jQuery is mentioned less and less because core browser APIs implemented a lot of what it does and made it unnecessary. Even if Web Components solve the “create a component” part of React there’s still an absolute ton of stuff it provides that Web Components don’t. I tend to think of WC as a low level API you want a library interfacing with rather than your own code, e.g. the way Svelte exports web components.
  - sdwr 2y ago
    The point isn't that it's a standard, it's that it's implemented in browser (not in a framework), and is a lot closer to the web equivalent of "bare metal". There are less moving pieces that will break backwards compatibility in the next 10 years (is the hope)
lmm 2y ago
> The upside is that web components will last longer than react components. How much are you betting? React components have been around longer and are more widely established, so personally I'd expect them to last longer.
- spartanatreyu 2y ago
  > How much are you betting? If you're prepared to put money down on it, I'd wager $500USD on longbets that Web Components will still function in 20 years. And I'd wager another $500USD on longbets that it will be easier to port a web component written in 2024 into a new project written in 2044 than it will be to port a react component written in 2024 into a new project written in 2044. The reason why I'm so confident is that Web Components are already a standard.
  - sieabahlpark 2y ago
    [dead]
  - stickfigure 2y ago
    I am not a betting man, but I would not be so sure. The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet. As someone who has been doing GUI development since 16-bit Windows, it's really remarkable to me how much staying power React has. It's 10 years old and still the dominant way of building web applications. I can't think of any other frontend library (web or native) that has had that long of a run at the head of the pack. What I'd be most concerned about with any 20-year bet is what new paradigm/library might come along and supplant the old ways. Standard or not, React has a critical mass that will keep it viable even if it becomes "legacy". If some new hotness makes web components look old-fashioned, the small community could disappear pretty fast - browser standard or no. Ask any XSLT developer.
    - spartanatreyu 2y ago
      > The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet. Web Components are used by internally by browsers to implement elements. As dannye stated (https://news.ycombinator.com/item?id=40292970 https://news.ycombinator.com/item?id=40292970): input, textarea and video are all web components. And since the major browsers have implemented those elements in that fashion I think it's safe to say they have most certainly reached widespread adoption. (even if most people haven't realized yet) > I can't think of any other frontend library (web or native) that has had that long of a run at the head of the pack. Flash and jQuery come to the front of my mind. React (or at least the React of today) will one day be looked back just as we look back at what came before it. I think it'd probably be fair to say we're at that point about 10 years after the record-tuple proposal goes through and the explicit resource management gets a syntactic sugar upgrade a la promises to async/await. They shift the paradigm enough that the old assumptions used when building our current frameworks will need to be re-examined. New frameworks will be able to blossom, and/or the current frameworks will shift enough internally that they won't resemble how they are today, and they will have to drop support for older code, or run slower compatibility layers that no one would want to use on newer projects. Even if one of those proposals fails to go through, we would still have other standards moving with enough momentum to eventually change the landscape. In the long term, I'm looking at a lot of capabilities being added to wasm to make compile-to-wasm look more attractive.
danielrhodes 2y ago
Your quote omits the qualifying part of that sentence, which is important. :-) What does it mean to "last longer" when it comes to your own codebase? And why would web components help with that?
- spartanatreyu 2y ago
  The linked blog post goes through that.

pier25 2y ago

> I don't think there's any inherent upside to using Web Components over React. What about using web components in a server rendered application without needing to resort to running JavaScript in the server?

junon 2y ago

Yep, pretty much. They're a pain to develop for but worth it if you're writing libraries.