4 ms·

> WCs are standardised and will continue to work basically indefinitely regardless of the ebbs and flows of popular libraries Help me understand; is this sugge

> WCs are standardised and will continue to work basically indefinitely regardless of the ebbs and flows of popular libraries Help me understand; is this suggesting that older frameworks/libraries are expected to stop working at some point? I'm shipping 10+ year old libraries in production without incident. Really don't understand the "resilience" argument for WCs.

pegasus 2y ago
10+ years is nothing compared with a human lifespan. Web standards are more likely to still be around in 50 years than react vX.
- teg4n_ 2y ago
  react uses those same web standards. It will not stop working either. You may not be able to upgrade to the latest React version assuming there are breaking changes, but the same can be said for the various frameworks people use to create web components.
  - IlPeach 2y ago
    I might be nitpicking but, the transpiled version of React is the one that uses those standards. If you are thinking of trying to get a 5+ years old project working in a development environment you might effectively be out of luck. To reduce the argument to a simpler one, this is effectively the difference between using vanilla js to build anything Vs using any abstraction over it that has a number of dependencies you don't control that are effectively a working solution of a dependency hell in a specific moment of time.
    - svieira 2y ago
      Yes, but then you are not comparing apples. Web components projects without a build step and relying on only stable standards are a subset of all web component projects. Same with React projects, though the ratios of without build vs. with build are obviously different.
    - teg4n_ 2y ago
      if JSX is your issue, that means a web component framework like Stencil is just as bad as React. But then again you can use React with htm to avoid jsx if it really bothers you.
edflsafoiewq 2y ago
A React component only works in React. WCs are self-contained and work like ordinary HTML elements. If in the future you don't use React anymore, you can keep using your WCs without change, but not your React components.
jakelazaroff 2y ago
Author here — have you never returned to an old project after months or years and found it difficult to get working again? Maybe a dependency doesn’t work with the current version of your operating system, or you’d like to upgrade some component that now conflicts with another? I’m not saying avoiding this needs to be a top priority on every project; some things just will not exist without ongoing effort to maintain them, and that’s okay! But for the other things, cutting the dependency surface area to an absolute minimum makes them significantly more resilient.
- Etheryte 2y ago
  I mean you don't have to look far, it was just two years ago that React 18 was released, where the way detached nodes are handled changed. That broke integrations with pretty much every legacy plugin that needed to do that, and you had to wrap it specifically for React. If you live fully immersed in the React ecosystem, then maybe it wasn't a problem, but for a lot of projects, it was a very painful upgrade. The change itself wasn't large code wise, but the fact that if you wanted to upgrade React for some reason, you also had to go touch and test all these old pieces of code, really did not do anyone any favors.

pegasus 2y ago

10+ years is nothing compared with a human lifespan. Web standards are more likely to still be around in 50 years than react vX.

teg4n_ 2y ago
react uses those same web standards. It will not stop working either. You may not be able to upgrade to the latest React version assuming there are breaking changes, but the same can be said for the various frameworks people use to create web components.
- IlPeach 2y ago
  I might be nitpicking but, the transpiled version of React is the one that uses those standards. If you are thinking of trying to get a 5+ years old project working in a development environment you might effectively be out of luck. To reduce the argument to a simpler one, this is effectively the difference between using vanilla js to build anything Vs using any abstraction over it that has a number of dependencies you don't control that are effectively a working solution of a dependency hell in a specific moment of time.
  - svieira 2y ago
    Yes, but then you are not comparing apples. Web components projects without a build step and relying on only stable standards are a subset of all web component projects. Same with React projects, though the ratios of without build vs. with build are obviously different.
  - teg4n_ 2y ago
    if JSX is your issue, that means a web component framework like Stencil is just as bad as React. But then again you can use React with htm to avoid jsx if it really bothers you.

edflsafoiewq 2y ago

A React component only works in React. WCs are self-contained and work like ordinary HTML elements. If in the future you don't use React anymore, you can keep using your WCs without change, but not your React components.

jakelazaroff 2y ago

Author here — have you never returned to an old project after months or years and found it difficult to get working again? Maybe a dependency doesn’t work with the current version of your operating system, or you’d like to upgrade some component that now conflicts with another? I’m not saying avoiding this needs to be a top priority on every project; some things just will not exist without ongoing effort to maintain them, and that’s okay! But for the other things, cutting the dependency surface area to an absolute minimum makes them significantly more resilient.

Etheryte 2y ago
I mean you don't have to look far, it was just two years ago that React 18 was released, where the way detached nodes are handled changed. That broke integrations with pretty much every legacy plugin that needed to do that, and you had to wrap it specifically for React. If you live fully immersed in the React ecosystem, then maybe it wasn't a problem, but for a lot of projects, it was a very painful upgrade. The change itself wasn't large code wise, but the fact that if you wanted to upgrade React for some reason, you also had to go touch and test all these old pieces of code, really did not do anyone any favors.