Hacker News Reader

Comment by lxe | Hacker News Reader

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.

View on HN

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.

Funny how this argument was opposed against libraries in the early days of programming.

I think it’s an argument for small, composable libraries. Think Go’s std instead of Java’s Spring.

UI components can be small, and customizable enough to do anything.

The HTML is an excellent exemple at that.

You are never "limited" by highly abstracted librairies since at any moment, you can write your fully customized one.

And no, a customized components is not immediately better.

Good Library UI components have, i18n, accessibility, and good mobile UX.

The comment "I can do a decent calendar in react in a few minutes" shows exactly this: it's infuriating to use on mobile.

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.

You know you can inherit the HTML date picker right?

... right ?

I actually don't know what you mean. Can you please tell me?

Webcomponents allow inheriting html built in elements.

https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

> Customized built-in elements inherit from basic HTML elements.

Thanks. I always wanted to look into web components, sounds interesting.

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.

> You could build a very complex UI with Ext.JS back in 2010 with a lot less code and very little time

What's stopping you from doing that now?

Hype

Developers care about functionality.

Designers care about uniqueness.

and their bosses care about both developers and designers being replaceable cogs in their company... else the bus accident test fails

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.

Component libraries like Telerik and Infragistics still seem to be going strong in 2022.

datasync / backend-for-frontend problem

Reply on news.ycombinator.com