I think rewriting UI systems every few years and reimplementing in various JS frameworks that come and go is a serious waste of manpower. I'd so wish people would embrace web components properly once and for all, with LitElement, Svelte or Stencil.
This way we won't have to live with another framework-bootstrap clone again and again and everyone can contribute to one solution that will work with all JS frameworks.
If I had to guess, I would guess that React will still be around in 5 years, but I'm not sure web components will. Sure, they may still be a part of the standard, but they might be so obscure that there isn't enough of a community around them to be a feasible option. So I don't think using web-components is the silver bullet you imagine.
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.
> If I had to guess, I would guess that React will still be around in 5 years, but I'm not sure web components will.
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].
It seems replication of numerous UI frameworks to be a fruit of Evolution per se, and it will happen again and again.
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.
I think you confused multiple things together - why do you bring webcomponents.org the website into discussion, it has no relation here.
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.
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.
Yes, but the website is not only for polymer elements, you can find components written in other libraries too, like lit, svelte or even vue. That's what I meant - it is just a website that serves as information aggregator from bower/npm.
heh, I've worked for companies that hit the max on cookie size (which I think is around 60kb). For an entire framework to be 60kb would be amazing for these companies :)
https://stefankrause.net/js-frameworks-benchmark8/table.html - thats old lit release there vs react 16 (react pre 16 would be slower and everyone agrees its generally fast already), on slack channel I believe I saw newer release benchmarks that are better (it also depends at which specific test you look at).
I compared my usual candidates: vue, inferno, Surplus and vanillajs, and lit-html was dead last overall in almost every category. Also slower than Preact now that I checked, so I'm not sure that performance benefits are one of lit-html's unique strengths.
Yup, notice that from the slack screenshot that I posted it has speed mark 1.18 that puts it before Vue in terms of speed (which makes it plenty fast IMO, and its not even stable yet), I never claimed it is the fastest one of the bunch.
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.
I don't know what you mean by "the performance question". A web component uses the same DOM APIs that React/etc. uses so it can have performance as good or better depending on how it is written.
The problem is coordinating rendering between components. React and similar frameworks optimise performance by batching DOM updates in one big read-compute-write cycle. With web components that don't share centralised DOM manipulation code its hard to see how that would work, and this can be a big performance problem.
