Component UI libraries have converged towards providing the most basic building blocks instead of creating higher levels of abstraction, which I personally think is a bad trend.
You could build a very complex UI with Ext.JS back in 2010 with a lot less code and very little time, while it takes a while lot more work to produce even something relatively basic with modern UI frameworks.
I really don't care about how customizable your spinner is. I want to use it in common contexts with as little code as possible. Heck, at least provide me with a kitchen sink so I can copy and paste common patterns.
Supplying the building blocks is how you're able to compose them into something different.
If all the UI libraries just gave you highly abstracted prebuilt components with little to no customisability, then you wouldn't use them. Because as soon as you want to do something different, you'd have to write your own or find someone else's.
What's shifted is that product/design want the UI to be distinctive to the company and its brand. So each company needs its own foundational UI library, or at least a highly-customizable third party one
For some apps. For internally-facing admin for example tools we want a minimal learning curve and readily recognisable, sign posted models. It needs to look like stuff you already know, down to icons and ux behaviour.
Being limited to highly abstracted libraries leads to worse UI because you have to shoehorn your app into the limited set of forms the library allows you to express.
If you just want some boilerplate UI in a hurry, this is fine (it’s actually better) but it sets an upper bound for how good the UI can ever be and that’s a problem for serious professionals.
Of course most UI is horrible but that’s true no matter what framework you give them. There’s always somebody using checkboxes as radio buttons.
The web is exactly a bad argument, it composes terribly. You can make n*m divs for the days for a calendar widget, it won’t be recognized as a date selector. While swing, or even earlier GUI iterations realized that inheritance is a very sane model for GUI frameworks.
An approach I like is to provide basic components (i.e. a toolkit) and higher order components that can be copied into the project as required. This allows maximal flexibility while also providing the possibility to DRY things up in your own codebase.
Tailwind and Tailwind components achieves this for example. Web components also come to mind.
"You could build a very complex UI with Ext.JS back in 2010 with a lot less code and very little time" I have not encountered a more complex and verbose library than ExtJS. I would never in a million years say "very little time" with ExtJS. I did not enjoy my time with it at all. And that was a whole lot of time, since it took forever to do the simplest of things.
I've had the same frustration. I want to go from intent to a UI as quickly as possible.
My intuition about solving this is to create components where instead of a select and a radio button being separate components, they're the same component with basically the same API.
And instead of deciding on a spacing between components, you just get spacing more or less automatically so everything looks good by default.
You could build a very complex UI with Ext.JS back in 2010 with a lot less code and very little time, while it takes a while lot more work to produce even something relatively basic with modern UI frameworks.
I really don't care about how customizable your spinner is. I want to use it in common contexts with as little code as possible. Heck, at least provide me with a kitchen sink so I can copy and paste common patterns.