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.

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.

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

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?

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.

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.

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

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.

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

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.

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.

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

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

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.

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

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.

3 Different things. html, css & js are like raw materials, React is processing these raw materials, and a UI components or design systems are the result you get if you mix the React process with manual labor.

The're frameworks and design systems. A React UI framework refines or enhances the React process to build UI components or design systems.

Bootstrap e.g. is 2 things in 1, it's a process/framework and design system that sits directly on top of html, css & js.

Try https://github.com/Polymer/lit-element for an alternative to VDOM, without the VDOM part. It's reactive and uses lit-html under the hood.

This is confusing. The only difference between if this were a web component vs a React component is that the consumer would not capitalize the name. Instead of `<Button appearance="primary">` they would do `<evergreen-button appearance="primary">`. That's it.

This is already a start: https://www.webcomponents.org/

Edge and Firefox are only missing Shadow DOM and Custom Elements, which they are already developing.

On mobile Web 100% of the browsers support Web Components.

https://www.webcomponents.org/

So what are the many popular browsers you refer to? As anything else is meaningless.

Yup, Polymer is "big" dependency, but with things like svelte, litelement or stencil you can build web components which have little overhead.

Also polyfills are separate thing from polymer - they are reused by ALL other frameworks including vuejs for example, so I'm not sure what you meant by that comment.

> I've seen so many job listings calling for extensive experience with Bootstrap, for example. Why would knowledge of CSS and the grid system not suffice there?

Because their current system might already be using Bootstrap, so they need someone who understands it to be able to continue the work.

There is 100% support on the mobile web across Safari and Chrome.

That's radically inconsistent. Angular is not HTML, nor Javascript, rather it's its own thing -- precisely a "little platform on top of the web", to use your phrasing.

That was my guess, but the_duke's comment makes me think there is more to it. I'll have to look at the code to see if the React components do anything more than apply HTML templates with associated CSS styles.

I think the_duke answered my question.

The reason I asked it is that, if you're building an HTML+CSS framework for use in React, then why wouldn't you separate out the HTML+CSS part, and then depend on this. That way it would be easy to re-use 90% of the work, if you then want to use the components with Vue or some other framework, or even for plain static pages.

Responsive design isn't just adding breakpoints.

It's responding to the device and the ways the user will interact with it. For example, the combobox example in Evergreen doesn't actually use a <select> in the background, so users on mobile devices will actually have to use the dropdown implementation rather than the browser displaying a proper native mobile select. That's a much worse experience. Not to mention Evergreen will be completely inaccessible for users who need assistive technology, which potentially poses legal issues...

My connection is fast enough too. I'm on Firefox though, so maybe that's the "issue", if their framework is designed to work mostly on Chrome and not the other browsers.

While I agree React isn't the issue here, you chose horrible examples. Loading Facebook on my computer (especially trying to open a chat window) brings my computer to a knee. And using twitter on mobile browser you quickly learn how the spinner looks.

There may be some fast components in the Reddit web app, but I think there must be a valid reason why so many users are switching to the old Reddit (not just because of the way it looks, but due to performance complaints). I just went in and even scrolling through Reddit comments is laggy. Switching to old mode is like day and night.

The new Reddit design is often much slower loading the first time than the old one. It's performant after that, but that first load is annoying.

There is an overhead, but the main problem with the new Reddit is not that it was made in React, but that it's a massive fuckup. Not only from a programming perspective but also design and UX.

> You can, for example, pass an object {string:booleanish} and it will add only the keys whose values are truthy.

Why is this something you can't do on your own in a few lines of code?

  const classNames = (o, c=[]) => {
    for (let k in o) if (o[k]) c.push(k) // booleanish
    return c.join(" ")
  } 

This is not cool at all! Why import a trivial function over NPM to do this for you? Better to lower your dependency count and have a "util.js" file for helpers like this.

Yeah, my React code is currently littered with conditions and `classNames.join(' ')`. I'm going to start using this library.

In ideal world all functions should be pure and be a dependency and all code should be just pure functions.

Second one is used only once in the code base to concat two strings together afaik

I was curious so I checked out their Github page. I found this example:

  classNames('foo', 'bar'); // => 'foo bar'
  classNames('foo', { bar: true }); // => 'foo bar'
  classNames({ 'foo-bar': true }); // => 'foo-bar'
  classNames({ 'foo-bar': false }); // => ''
  classNames({ foo: true }, { bar: true }); // => 'foo bar'
  classNames({ foo: true, bar: true }); // => 'foo bar'
  ...
  var btnClass = classNames({
    btn: true,
    'btn-pressed': this.state.isPressed,
    'btn-over': !this.state.isPressed && this.state.isHovered
  });

Look like the button example is a good enough convention for me, I don't need any of the other conventions. Can anyone tell me why this is not sufficient?:

  const classNames = (pojo, c=[]) => {
    for (let k in pojo) if (pojo[k]) c.push(k);
    return !!c.length && c.join(" ");
  }

Do I need array-flattening support, multiple argument support? The size of this library probably comes from it supporting a handful of different coding styles. I would say the size (50 lines) is too large, if anything. Dependency worthy? I'm not convinced. I am very much so against requiring trivial utility functions from other people. Roll your own if it's trivial! It's better than depending on something over the network.

arrify(null) returns null, unlike the arrify library . I expect that a function which turns things into an array returns an empty array as fallback. This ist just an example for why one would favor well-tested utilities over re-inventing the wheel (not that I would use arrify as a dependency myself).

Why would that matter for learning typescript..?

Most low effort way is to search the repository on GitHub for the require.

Also worth noting the ones I listed aren't transitive dependencies. Those are both explicit dependencies of this project