Posted 5 months ago and the discussion revolved around the weird license: <a href="https://news.ycombinator.com/item?id=31791324" rel="nofollow">https://news.ycombinator.com/item?id=31791324</a>
I am so hoping for a CSS-only (or at least CSS-mostly) library to come along, especially one that is fairly complete, designed for the long term, and usable for (boring) large applications and data-dense tables. I do not need a full JavaScript "framework", I have a React app (in ClojureScript) and I'm fine, thank you.<p>I've been living with Semantic UI which got many things right, but has been abandoned for quite a while now.<p>Most things that capture the crowd attention are humongous piles of JavaScript with a bazillion dependencies, that will likely be out of fashion in a year or two.
I’m coming around to a front end philosophy lately that shuns “all-in-one” component libraries entirely, because it’s a fantasy that never really plays out in reality. Take just tables for example; every component library has their own table implementation, and they all fall short in some fashion. Either they lack sufficient filtering, or their rendering performance nosedives with large datasets, or they enforce some kind of data structure that doesn’t work for you. So you end up pulling in a specialized table library and theming it to fit your needs. Now you have two redundant table components in your codebase, and it can be really unclear to new contributors which should be used where and why. Repeat ad nauseum for dropdowns, modals, etc. and all of the sudden the vast majority of your initial component library choice becomes dead weight.<p>Better to build your own simple primitives using Tailwind, (buttons, text, popovers, cards, and the like), then selectively pull in specialized components that solve one single problem thouroughly, and have widespread OSS support and usage.
Not a very accurate title<p>> The Elastic UI framework (EUI) is a design library in use at Elastic to build internal products that need to share our aesthetics
The tree view and data grid components don't seem to support lazy loading elements, which is particularly disappointing given how frequently I end up implementing that functionality in front of ElasticSearch and Solar.<p>Apologies if I'm overlooking something that simply isn't documented prominently. (FWIW I do see the pagination support on the grid, but I'm looking for fluid vertical and horizontal scrolling)
I really wish that everyone who was investing this much time into design systems would implement the primitives as Web Components.<p>It's trivial to wrap Web Components to work with pretty much any framework, and most support them out of the box.<p>It's hard or impossible to go the other direction though.<p>Also, you get bound to framework versions and end up in the endless upgrade hamster wheel.
I was hoping it would use something akin to openai or SHEX to describe the data inputs and outputs for components. Instead, it as others say, another React component library that uses design tokens.