Also, I haven't seen a lot of companies saying "Well, Angular is working great for us, but React is hot and trendy so let's rewrite the current UI in it". Rather, I think UI framework switches happen for two reasons:
- They've accumulated so much technical debt with their existing solution that progress has slowed to a crawl, developer morale is really low, etc. A migration strategy can be found that doesn't have such an upfront cost, and will dramatically improve velocity as features are converted.
- The design is totally changing, or the product is being rethought, and so it's not an invisible code rewrite, it's essentially building a new product.
I think in both of these cases, it's a good use of developer time.
I agree, and this is why I use React (or rather Preact) for both apps and interactive elements on the page. The big caveat is that in practice it's really easy to end up with a React project that is much more difficult to maintain compared to a monolithic framework (Ember, Angular, Vue, even), because of all the other crap that might be used to take care of all the stuff React doesn't do.
For example, I recently took on a React project that used a whole bunch of other packages for state management, routing, etc., and a number of those packages were no longer supported (or outright compromised). While it's nice that React is still React, a lot of these other packages are tightly woven into the whole 'fabric' (react-swipeable-redux-router type stuff).
For my part, when I start a React project I try to minimize these problems by generally avoiding react-specific packages. So instead of react-router (which had its share of non-backwards-compatible updates), I'll just use page.js for routing. In some cases I might use the reactified version (Redux comes to mind, but I avoid that most of the time for smaller stuff).
This still isn't a panacea, and as a result I've been moving more and more stuff to a more 'vanilla' Railsy backend (Elixir/Phoenix, specifically). While the ecosystem does seem to be stabilizing a bit, it's still insane, and thankfully there are or will be ways to still add a bunch of 'dynamic' shit to the front-end without drowning in this insanity [1].
You named Web Components, I've been embracing them for a while, but if you tried to switch from Google's Polymer to LitElement it wouldn't go smooth as you could have imagined. Both Polymer and LitElement are based on Shadow Dom and WC features curated by Google, but are not 100% backward compatible. That is to say, Web Components have been divided from within the same tech. No need to mention the rival concepts of "everything HTML" of Polymer 2.0 and fixing it to be "all JS and webpack-ready" in 3.0, and consequential deprecation of Bower.
And here you mention some Svelte and Stencil which I've never heard of before. Why need them? We have webcomponents.org already.
Web components are a low-level primitive - they are clunky to use directly.
Polymer and LitElement - are libraries - you can author WC's with them. And yes they are different (I used both), but you don't really have to migrate from one to another.
Web components are not divided - Lit-element can work within vuejs or polymer or angular for example. VueJS authored WC's can work within lit-element or polymer.
https://custom-elements-everywhere.com/ - see this for more information about interoperability (sometimes it depends on templating syntax).
You asked about Svelte and Stencil - https://svelte.technology/, https://stenciljs.com/ - those compile your code into web components - different approach than polymer that is a suite of quite a few higher-level abstractions that you might not want to pay for (20kb of js).
Don't know what you mean by saying it has no relation; I've been using that site for searching components while developing my PWA based on Polymer. I can install components with yarn or npm just fine, using instructions and examples from there.
React was released in 2013, has only had minor breaking chanhes since then, and doesn't show any signs of disappearing anytime soon.
New version of repeat is interesting:
Nicoburns said that "performance question is not solved" - I think we can agree than svelte and lit are fast in general, that was the point I wanted to make that it is the implementation that matters here.