4 ms·

> The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet. Web Compon

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

stickfigure 2y ago
<software that is used internally in some popular software> doesn't grant network effect - after all, the team(s) that maintain the software could replace the implementation and nobody would be the wiser. The countless humans trained to write React code are harder to fix. Flash and jQuery are contenders, but still aren't comparable. They didn't run as long at the head of the pack, and the web (and web development community) was much smaller back then. React is still going strong. I agree with you, all things (and especially all technologies) end. But I'm not ready to speculate what the post-React world will be like. I don't think we've even seen "peak React" yet.
- spartanatreyu 2y ago
  I agree that those implementations could be changed. I doubt the standard will be going anywhere since there are some sites that already use them. Altering Web Standards in such a way that may break old sites is abhorent to Web Standards bodies. (See the array.contains prototype discussion: http://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible http://esdiscuss.org/topic/having-a-non-enumerable-array-pro...) > Flash and jQuery are contenders, but still aren't comparable. I would contend that they are. Flash was enormous, it was installed for 92% of all internet users. (Source is wikipedia, they've rewritten the page, but it still appears in google's cache, search: "flash player 92%") It wasn't just the standard, it was the industry. Jquery too used by at least 76.9% of all websites, compared to React at 4.2% all websites. (source: https://w3techs.com/technologies/details https://w3techs.com/technologies/details) > But I'm not ready to speculate what the post-React world will be like. I am. React is currently adding web component support right now. TC39's tuple/record propsal will reshape dataflow in component libraries/frameworks. Eventually we will get syntactic sugar for explicit resource management to make it easier to use a defer style setup/pulldown like in other languages. Both of those (plus the decorator proposals + extensions) will change the dataflow and ergonomics of the js landscape. Frameworks will adapt into new shapes of be supplanted. If react wants to keep adding new ways to do things to hold onto the "react" brand then by all means, but even now it wouldn't be unfair to say we're in a post-<this kind of>-react and a post-<that kind of>-react world.
  - stickfigure 2y ago
    ...and yet standards bodies do deprecate standards that fall out of use. WebSQL and XHTML come immediately to mind, I'm sure there are more. Not that I'm predicting Web Components will go that route, but - given a long enough timeline - I don't dismiss the possibility. Flash and jQuery had their time in the sun, certainly, but not as long as React, and the web (and web development community) in the 2000s was tiny by modern standards. Also, I don't believe that "user installed base" is an important metric - "number of programmers deliberately writing software with it" provides the network effect. If anything, your point about the ubiquity of Flash reinforces my point that "web standards" can change pretty suddenly when mindshare changes. The writing was on the wall, but the iPhone really killed Flash. "Web Components now" has been the "year of the Linux Desktop" refrain of the webdev community for a long time now. It's possible (just like Linux on the desktop is), but given the history, my prior is to be skeptical. And it's possible we haven't yet seen the hit product (eg iPhone) that reshuffles the technological landscape. Do I think WCs will disappear anytime soon? Certainly not. Do I think it might end up being part of plumbing underneath frameworks like React that nobody thinks or cares about? Possibly. On a 20-year time scale, will web technologies as a whole be disrupted? Possibly.
1oooqooq 2y ago
> used internally and that's why it's going to fail. you cannot do something based on progressive enhancement and not repeat tons of html with web components. but i guess that's why we have noscript tag. /shrugs

stickfigure 2y ago

<software that is used internally in some popular software> doesn't grant network effect - after all, the team(s) that maintain the software could replace the implementation and nobody would be the wiser. The countless humans trained to write React code are harder to fix. Flash and jQuery are contenders, but still aren't comparable. They didn't run as long at the head of the pack, and the web (and web development community) was much smaller back then. React is still going strong. I agree with you, all things (and especially all technologies) end. But I'm not ready to speculate what the post-React world will be like. I don't think we've even seen "peak React" yet.

spartanatreyu 2y ago
I agree that those implementations could be changed. I doubt the standard will be going anywhere since there are some sites that already use them. Altering Web Standards in such a way that may break old sites is abhorent to Web Standards bodies. (See the array.contains prototype discussion: http://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible http://esdiscuss.org/topic/having-a-non-enumerable-array-pro...) > Flash and jQuery are contenders, but still aren't comparable. I would contend that they are. Flash was enormous, it was installed for 92% of all internet users. (Source is wikipedia, they've rewritten the page, but it still appears in google's cache, search: "flash player 92%") It wasn't just the standard, it was the industry. Jquery too used by at least 76.9% of all websites, compared to React at 4.2% all websites. (source: https://w3techs.com/technologies/details https://w3techs.com/technologies/details) > But I'm not ready to speculate what the post-React world will be like. I am. React is currently adding web component support right now. TC39's tuple/record propsal will reshape dataflow in component libraries/frameworks. Eventually we will get syntactic sugar for explicit resource management to make it easier to use a defer style setup/pulldown like in other languages. Both of those (plus the decorator proposals + extensions) will change the dataflow and ergonomics of the js landscape. Frameworks will adapt into new shapes of be supplanted. If react wants to keep adding new ways to do things to hold onto the "react" brand then by all means, but even now it wouldn't be unfair to say we're in a post-<this kind of>-react and a post-<that kind of>-react world.
- stickfigure 2y ago
  ...and yet standards bodies do deprecate standards that fall out of use. WebSQL and XHTML come immediately to mind, I'm sure there are more. Not that I'm predicting Web Components will go that route, but - given a long enough timeline - I don't dismiss the possibility. Flash and jQuery had their time in the sun, certainly, but not as long as React, and the web (and web development community) in the 2000s was tiny by modern standards. Also, I don't believe that "user installed base" is an important metric - "number of programmers deliberately writing software with it" provides the network effect. If anything, your point about the ubiquity of Flash reinforces my point that "web standards" can change pretty suddenly when mindshare changes. The writing was on the wall, but the iPhone really killed Flash. "Web Components now" has been the "year of the Linux Desktop" refrain of the webdev community for a long time now. It's possible (just like Linux on the desktop is), but given the history, my prior is to be skeptical. And it's possible we haven't yet seen the hit product (eg iPhone) that reshuffles the technological landscape. Do I think WCs will disappear anytime soon? Certainly not. Do I think it might end up being part of plumbing underneath frameworks like React that nobody thinks or cares about? Possibly. On a 20-year time scale, will web technologies as a whole be disrupted? Possibly.

1oooqooq 2y ago

> used internally and that's why it's going to fail. you cannot do something based on progressive enhancement and not repeat tons of html with web components. but i guess that's why we have noscript tag. /shrugs