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.
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.
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.
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.
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 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.
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.
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.
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?
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.
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.
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.
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.
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.
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).
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
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.
https://element.eleme.io/
https://ant.design/
https://quasar-framework.org/
https://at-ui.github.io/at-ui/
https://developer.microsoft.com/en-us/fabric
https://vmware.github.io/clarity/
http://appnexus.github.io/lucid/
https://ng-lightning.github.io/ng-lightning/
https://blueprintjs.com/
http://www.jetbrains.org/ring-ui/
https://www.lightningdesignsystem.com/
https://elastic.github.io/eui/
https://atlaskit.atlassian.com/