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

[1]: https://www.youtube.com/watch?v=Z2DU0qLfPIY

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.

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

Thanks for links you provided.

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.

Problem is, web components don't provide the same thing as frameworks like React. And the performance question still hasn't been solved.

React was released in 2013, has only had minor breaking chanhes since then, and doesn't show any signs of disappearing anytime soon.

Lit-html is faster than react + vdom - and has 6kb instead of 60kb. And back in the time everyone used jquery, the arguments are always the same.

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 :)

Wow - 60kb for cookies is crazy.

Where's the benchmark showing this?

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

New version of repeat is interesting:

https://slack-files.com/T03PF4L4C-FCY51FZAB-c2fcf32931

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.

There you go, https://rawgit.com/krausest/js-framework-benchmark/master/we..., much faster than vue and react (still not inferno speed yet, but the gap is closing).

Not bad. I'm always amazed at Surplus though, that's the one to beat!

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.

obligatory xkcd:

https://xkcd.com/927/

Sure, if it works now, it'll work ten years down the line as long as they're not doing anything nonstandard.

There's a big fear that projects that become unmaintained suddenly stop working; this isn't correct.

Besides, all webapps are rebuilt in a 3-5 year cycle anyway so it really doesn't matter.

Do you feel like rewriting a bunch of webapps written in Perl/modapache around early 2000?

I know of at least one company with such a stack. Just like I know others with Web Forms, Stucts, SEAM, JSP, Zope and many other stacks in production.

Not everyone re-writes their webapps, specially in companies where software is a cost center and totally unrelated to their main business.

Sure, I'd be happy to. Converting apps from an old platform to a newer platform is reliable work, and I've done my share of it over my career. It often is structured as temporary projects, so I've had the opportunity to travel to short-term gigs in new cities while I build out platform conversion plans.

Sure, not everyone re-writes old apps. But enough companies do it to make it a decent professional specialty to cultivate. And it doesn't hurt knowing both the modern stacks and multiple generations of legacy stacks when working with large organizations. Sign me up.

> There's a big fear that projects that become unmaintained suddenly stop working; this isn't correct.

While true, it only applies if you don't want to upgrade your lower level dependencies, ever. And given that this is a React based framework, so it's not based directly on the web platform, if it's not maintained, you'll have to port the framework yourself.

Coversely, if it is maintained, you may be forced to keep up and upgrade whatever this is based on, or backport fixes if the project moves on to a newer incompatible version of the lower level dependency.

> Besides, all webapps are rebuilt in a 3-5 year cycle anyway so it really doesn't matter.

Eh? :D I still iterate on 13 or 9 year old codebases for my clients without re-building anything.

> Besides, all webapps are rebuilt in a 3-5 year cycle anyway so it really doesn't matter.

And I thought places I worked at tended to be terrible :/

"Works" and "is maintained" are two very different things.

Ten years!? It will break two months from now via some ill-thought-out npm push update.

Jetbrains would be my bet. They'll look after it even if it doesn't become the most famous library.

Jetbrains is the new Borland, but I hope that their management doesn't come up with an Inprise idea.

Thank you for this comment. I hadn't noticed that they had a ui library and I agree that they'll probably take care of it even if it's not popular. Very nice.

They're open source right? Would you expect to build your own design language, responsive/accessible components, documentation and maintain it any better than an open source solution?

These frameworks are inevitably much more generic than any in-house solution. On one side this is great, because it means that the abstractions need to be sensible - but it also means there is much more code to maintain. So yes, sometimes maintaining your own solution will be easier than maintaining an abandoned opensource solution. Of course, even better would be to use a solution which will not be abandoned.

Also note that these frameworks lock you into design & feel of their choice. This might work for some use cases and for now, but when the requirements change you often end up fighting the framework. I don't have a solution to that though. :)

> So yes, sometimes maintaining your own solution will be easier than maintaining an abandoned opensource solution.

I'd argue this depends on your needs. If you're using one of these for your consumer-facing product, perhaps so. Otherwise, if your UI is not what you're selling or your product/team is big enough to end up creating one of these from scratch anyway, then no. In the latter case, that's probably why there's so many of these to begin with.

> Also note that these frameworks lock you into design & feel of their choice.

Some of these frameworks actually let you re-theme them. For example, Ant Design can mostly be re-themed.

That's a false dichotomy. The third option is the obvious one: use a framework that will be well-maintained.

The alternative is to write all of the components yourself.

Using one of these frameworks helped us avoid that cost upfront and get the product out the door. If our company is still around in several years, I'll happily maintain it myself (or hire the original author).

EDIT: This comment assumes the framework of choice is open source.

If you pick one made by a big company, it should be fine.

That's what I thought when I integrated Google Wave into my companies workflow...

/s

I noticed the sarcasm, but, Google Wave never got out of beta (iirc) so anyone seriously adopting it knew what they were getting into.

Same with gmail which was in beta for years for some reason - probably because they wanted to avoid liability for lost data etc.

Since this thread is about frontend, what about angular 1? Everyone who was using angular 1 because it was "backed by Google" got screwed hard on that one.

I'm doubting there is any liability for lost data now that it is out of beta.

Google is the exception that proves the rule.

How's your Silverlight app working out for you? Does it still connect to your WebObjects server?

I prefer WPF :-). Touche, but Google has more of a habit of killing off perfectly good stuff. But MS does it too. With Silverlight market forces, especially HTML5/mobile and Apple policies most likely killed it.

Or Angular v1

We're very productive with Angularjs...