The question is: how many of these will be maintained several years later? Can you build a long term project on these?

Or the expectation is that one has to make a new UI anyway every several years to keep up with the changing fashion, so rewrites are inevitable?

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

We've been happy with http://react.semantic-ui.com/ so far.

I liked Semantic-UI a lot in terms of looks, but the React aspect of it is separate, so even though it's done by the same people as the core team, it inherently always lags behind a bit in feature completeness. I especially ran into this with transitions and animations, and migrated to Blueprint.js instead, which I was extremely happy with from a feature-completeness perspective, but which I couldn't figure out how to theme.

It's not done by the core team. It was a separate project by separate people that was brought under Semantic UI's umbrella. That's actually the major reason for the lagging behind: Semantic UI is designed for a circa 2008 jQuery website. It's a beautiful UI, but the CSS uses a horribly dated model which obligates child elements being aware of the parent elements.

End of the day, until it's rewritten with modularity in mind it will always be a drag to properly implement it in React.

I can second this. Semantic was never set up with real modularity in mind. There is tons of relational knowledge you need to have to make anything work well.

I looked at many of these for an assessment at my company. We started a little broader with some css-only solutions as well but they tend to only take you so far; the controls are nice. Key aspects for us were (1) React-based, (2) TypeScript support (bonus for native TS), (3) Applicable to data-dense engineering apps, and (4) a broad-based, healthy ecosystem. I also evaluated Semantic-UI React.

I really like Blueprint JS but I think we'll end up building on top of Ant Design. It's a huge collection of work; they've also started to push Ant Pro which is higher-order components targeting building of admin apps (more opinionated, more than just a UI facade).

I'm in a similar boat as you. We actually started building on top of Ant. However, we first started out by building out our Admin pages and they were built with Blueprint.

I like Blueprint a lot more than Ant, but Blueprint doesn't pretend to support responsive applications[1], which was somewhat important to us. Blueprint exposes a couple building blocks (like PopOver) which really help in building more custom functionality. It actually looks like Evergreen be closer to Blueprint in this regard so I might piss off all the devs and evaluate Evergreen.

[1]https://github.com/palantir/blueprint/wiki/Frequently-asked-...

I've been using Blueprint and pairing it with Basscss for some responsive assistance and it's been successful (and a lot of fun).

I will look into this since I am on BP3 on a project and it seems that they will eventually want responsive support.

Can you elaborate on how this works? Thanks!

Gladly. Blueprint provides all of the "components" and I use Basscss to lay them all out in responsive containers.

I use Basscss' grid and flex helper classes to define how my I can create a 3-column responsive layout with something like:

    <div class="clearfix">
      <div class="col md-col-4">
        <SomeBlueprintComponent />
      </div>
      <div class="col md-col-4">
        <SomeBlueprintComponent />
      </div>
      <div class="col md-col-4">
        <SomeBlueprintComponent />
      </div>
    </div>

There's also a couple of other helpers like `max-width-*` which ensure responsiveness as the screen grows larger. Things like adding the `Classes.FILL` (which causes a button/control to go full width of its container) are useful for making things seem more like mobile (where buttons often are full width of the device, minus padding)

All in all, while it's a slight bummer than Blueprint isn't just responsive out of the box, I haven't really found that to be a deterrent to getting things done.

Have you looked at CxJS? CxJS offers chart controls and advanced data tables which makes it perfect for building admin apps.

https://cxjs.io/

I tried both BlueprintJS and Ant Design on two different projects I am handling.

While BlueprintJS is more intuitive, I find that it lacks a lot of built-in components compared to Ant Design.

Great list but missed a big one: https://material-ui.com/

Do any of these produce finished output that is less than a few kB, and works reliably in say the past two major versions of browsers? Bundle sizes are getting ridiculous.

Is there a React UI framework that focuses on tiny build size and browser compatibility?

Wouldn't any of those fit the case if you just do tree-shaking?

You have to specifically write code that supports that, so no. Look at the limitations of tree-shaking for more info.

Rebass.

Not sure what their bundle size looks like but my understanding is they're using PJAX so the site output should function without JS. Problem is good luck maintaining that stack and remaining secure. And then there's the fact there's no conceivable way it could scale properly for large sites static which would need something like Go/Rust to actually generate quickly then there's the matter of caching. Basically this all leads to headaches just in different places.

Thanks - that's a great list.

Some of them (atlaskit, MS fabric, Jetbrains, vmware etc) are geared towards building an integration withing those company's products. Whilst they can be used independently (without assets in Fabrics case, and other restrictions in the others), my take is the Evergreen (and ant, etc) are geared towards isolated products, similar to Bootstrap.

If you're building an addon for use in an Atlassian product, or an Office 365 product, these are a great way to stay consistent with the host application's look and feel.

Definitely be careful when using some of them e.g. Atlaskit because they are designed specifically for integration.

And if you use it for something else you may not comply with the license.

Another to add to the list: https://instructure.design

(Disclaimer: made by my coworkers)

Scrolling momentum is broken on iOS for me, it makes the page very frustrating to read.

Thanks for the feedback. I’m on the team building out this library. We have plans to overhaul our documentation soon and we’ll be sure to address this.

feedback: if I click on any of the sample buttons, the page is reloaded

Shopify also has one:

https://polaris.shopify.com

Personally, I've found Ant Design to be the most comprehensive, feature and behavior-wise.

Just clicked around and here's a note from the elastic/eui repo

" WARNING While open source, the intended consumers of this repository are Elastic products. Read the FAQ for details."

Doesn't instill confidence.

Hi. I maintain the library along with some others at Elastic. That warning is essentially us being good open source citizens and being very clear about how we maintain it. A lot of these other libraries are built specifically for their own products, no different then us. We just wanted to make it clear that the direction of the library and its maintenance is primarily driven by the needs of Elastic, rather than as some general community UI kit.

All that said, it certainly works fine as a general kit, and we build it with that practicality, it's just not something we officially support.

As far as stability, my team is pretty well resourced (and growing if there are any engineers interested!). We're using the library in many places around Elastic and its not going away anytime soon.

I've looked through most of the kits out there and they all have their pros and cons. Likely our biggest selling point is that it aims to be fully accessible and comes with a lot of fun charting libs. That puts its sweet spot for use in enterprise applications. It's also completely themable with about 8 lines of Sass variables.

Ace, thanks for elaborating. You could perhaps add a shorter version of this explanation to your README to make it clearer to others as well.

The point of the warning is to indicate that it's intended purpose is to be used with other elastic open source projects like elasticsearch and kibana. It's not a general purpose UI kit like the rest of those links.

I posted this list. FYI: It was specifically about UI frameworks backed by big companies, not every major framework available. There are lots of purely community-owned projects too.

https://grommet.io/ is awesome too.

I can recommend Element (the top of the list) -- I've used it on two projects now and it's been pretty refreshingly easy to use and relatively easy to integrate with (when you need to hook into components to make them act a certain way, for example a paginated table).

I made a graph showing download counts of those packages on npm - https://npmcharts.com/compare/carbon-react,material-ui,antd,...

Obviously don't use that as a sole factor to determine what to go with, but with this many options, heuristics may be helpful to narrow down which ones to further investigate

material-ui is deprecated, try with @material-ui/core.

Hot damn

https://npmcharts.com/compare/carbon-react,antd,@blueprintjs...

Material-UI is by far the most complete of the frameworks in my opinion having used a bunch of them, and constantly updated. It's a joy to work with.

Here are some more, separated out by React, React Native and Universal:

https://habd.as/awesome-react-components/

https://habd.as/awesome-react-boilerplates/

Just added evergreen to the components list as it doesn't look like more than a UI kit.

Wouldn't React-native-web ( https://github.com/necolas/react-native-web ) qualify into this list ?

It offers APIs compatible with React-native (which is obviously a huge time saver for cross platform UI dev).

Its disadvantage is that it does not offer (by intent and philosophy) any components outside of React native.

Yeah but how many of them are modern and elegant?

And SAP's OpenUI5 - https://openui5.org/ - https://openui5.hana.ondemand.com/#/controls :)

I'd also include https://reakit.io

google material components

https://github.com/material-components/material-components-w...

Would also throw https://www.carbondesignsystem.com/ into the mix! We're the design system for IBM :)

What about PrimeReact? https://www.primefaces.org/primereact

From a 5 min glance, this framework looks really inaccessible. Most outlines ("focus rings") are removed and it's really hard to navigate the components with a keyboard, even as a sighted person. The focus indicator for buttons is just another shade, which is not sufficient. I was not able to set a value in the "Rating" component using my keyboard.

All those things can be fixed, but I would rather go with a library with accessibility in mind.