The theory of UI libraries is that users can take their knowledge between applications. When you start using a new app, you already know mostly how it will behave, because it shares the UI vocabulary with other apps.

The web has been terribly violent to this idea. Native UIs are expected to support keyboard navigation, keyboard shortcuts, a menu bar, type select, drag and drop, accessibility, scripting... And in any given interaction there are advanced modes: multiple selection, modifier keys, etc.

Hardly any of this works on the web; even if it did you wouldn't think to try it. Does type select works in GMail's custom context menu? Can you command-C copy a message in one folder, and paste it in another? Would it even occur to you to try those things?

That stuff is ancient I know, and it would be one thing if the web were pioneering new UI vocabulary that displaced the old. But it's not. There's nothing new that has taken hold, no replacement for what is lost. Gmail has its janky, app-specific keyboard shortcuts, which is at least something, but there's no mechanism for it to spread.

We're in a Dark Age. Every web page now has its own custom CSS-style menu that only supports the most basic hover-and-click, and the bar for good UI is just lying on the floor.

As a person who has to use those web apps that supposedly "eclipsed" native applications, I hope this stage will pass, and we're back to the sanity of consistent UI across apps and frameworks.

Isn't it also a reason why it's said that accessibility sucks on the web?

Just so I'm following properly, do you mean something like how you have {React | React Native | React VR} + a cornucopia of community-supplied custom components? imo it's a system that works well - you have a common system + easily extensible custom bits.

(take my experience with a grain of salt, I've only used React on side-projects, never anything complicated or that I was forced to develop on because of work, and never ran into any perf issues)

Not the person you replied to, but that's what I imagine he/she is getting at. What I think of when someone mentions a Unix UI library is something like Qt, which provides a number of conventions, such as:

- Standard layouts

- Standard input and display components

- Standard event and message handling

- Standard user interactions

- Standard color themes

Which is great for developers to set up an initial UI, but makes every application look the same and takes a lot of work to customize in a way that's consistent with the defaults.

On the other hand, building a complex, feature-rich UI requires a lot of skill both in terms of implementation and design, which is less than common. So that Qt UI will be functional and predictable to users, even if it was not very well thought out, and the broken web UI will be useless to everyone.

This is exactly why I like to use these UI toolkits, and despise most web "UI" frameworks. That uniformity is why these applications are usable and predictable, and yes, boring. Deviating from the defaults takes effort, and that's a subtle hint that it's something to reconsider. You're deviating from the norm, and that might indulge a developer's whims or the demands of a manager who wants their application to stand out from the crowd. But that superficial difference is something I've despised ever since we have WinAmp and XMMS skinning the UI like many media players, purely to look different at the expense of usability.

Even after reading lots of UI guidelines, and developing several tools and applications, it's taught me that I'm terrible at it, and should let an expert do that part while I stick to the other parts!

Personally I like consistency. I've actually moved away from GUI apps in general because the terminal is more consistent, so I feel like there's less to learn with each new tool.

Yes, I should’ve said UNIX-philosophy or something... what I said was pretty ambiguous. I meant UNIX-style in terms of single purpose tools that work together over a common bus without being tightly coupled.

Not actually UNIX UI libraries.

> I personally would prefer to see a UNIX-like UI library made of many composeable parts. With idependant codebases.

OK, and those parts ought to be shared libraries.