[pdrummond]

I've been building UI for years now and all these points highlighted by Dan are spot on. Great post!

I've been thinking lately about the "design system" trend that is becoming more and more popular where companies want more control over styling and behaviour to make their UX unique to their brand as well as consistent across all their products. Ready-made 3rd party components like the excellent react-select don't really fit into this world as general purpose components like this naturally have to make some choices regarding styling and behaviour. No matter how customisable they are, in the end they rarely integrate well into a UI based on a design system.

This makes me feel like the abstraction is all wrong. Rather than aiming for fully-functional, out-of-the-box components that cater for all manner of general purpose requirements, how about a library/framework that focuses on a set of primitive components that deal with the lower level concerns like layout, scrolling, positioning, etc. Maybe the abstraction could be more like "composable shapes" than "ready-made components" or something along those lines.

With this approach, you wouldn't ever start out with something like a ready-made Autocomplete component, for example. Instead, you would always build a custom Autocomplete and have complete control over styling and behaviour, but it would be built from solid foundations using some form of the "shape" abstraction. That way, you can focus on making the component's styling and behaviour consistent with the design system without having to worry so much about layout, accessibility, scrolling, positioning, etc - as all of these are taken care of by the framework.

[danabramov]

That's exactly how some of the newer libraries in React ecosystem work btw. For example, Downshift is that "DYI Autocomplete" — it handles a11y and mechanics but you can compose any kind of behavior and styling out of its primitives.

https://github.com/paypal/downshift

I'm glad to see this trend.

[dandellion]

> a11y

I had to look that one up. I find it amusingly ironic that an accessibility initiative uses an abbreviation that renders the name incomprehensible.

[strokirk]

It's certainly ironic, but most places I've been to pronounces it like the word "ally". At least it's easier than the even more obscure "i18n" and "l10n" for "internationalization" and "localization".

[pdrummond]

I've used Downshift before and while I like the idea, what I am suggesting is broader in scope. A set of primitives such as Overlay, Rectangle, Circle, List, Row, Column, etc that still allow you to apply styling but overall they sit at a lower level of abstraction than ready-made components, even ones based on something like Downshift.

The more I think about this the more I feel like I'm describing exactly how "Qt Quick"[1] works, the declarative user interface markup language that is part of the Qt Framework. Of course, it's not a web technology but it would be interesting to see a web-based framework/lib based around some (if not all) of the ideas found in QML.

[1] http://doc.qt.io/qt-5/qml-tutorial1.html

[simplify]

It sounds like you're describing flutter. But that's not quite a web technology either.

[sephoric]

This is why I always liked Cocoa (macOS native UI toolkit) and still prefer it over web UI when writing native apps. It separates out the concepts of layout, appearance, and behavior, and lets you customize any one of them without needing to readjust the others. I just released an app this morning here that uses a non-trivial amount of Cocoa, and it would be full Cocoa if there was a Cocoa-version of the excellent Monaco editor. I feel like there should be a web version of this sort of "old-fashioned" toolkit that has a timeless ease of use once you get over the learning curve.

[hakfoo]

I always blamed it on the fact we stopped adding HTML tags too early.

There were a lot of UI elements that were obviously needed if you were going to use a browser as an interactive app platform, but were easily passed over when minimal forms were considered sufficient.

I could see, for examples, a consistent WYSIWYG edit-box, a dropdown menu construct, a select-with-manual-override, consistent date and time widgets. Instead we got a bunch of inappropriate elements glued together with CSS and JavaScript to sort of work, but in unpredictable, non-native ways.

[gedy]

That's a great point and something I've seen dealing with multiple look and feels at a single company. While not quite as far as what you suggest, we've had good success building components with no custom CSS at all and instead use Bootstrap classes exclusively. This allows a lot of freedom for the design system to look at it needs, but encapsulates the "hard parts" as you list. We've struggled with react-select as well, but were able to mostly specify various props to use Bootstrap classes. Not a sexy approach, but it works.

[audiolion]

Headless react components handle logic and state management and then pass data and handlers to their child components so whoever consumes them can determine how they look. Typically that pattern is called render props in react. Before render props the goto for this was higher order components which would wrap a component you style and make.

[tenaciousDaniel]

Totally agreed.

A modal, for instance, cannot be an independent isolated component. Because at the very least it needs to display an overlay over the entire page, which means that the modal trigger must have some way to communicate with an element at the root of the document. Those are architectural decisions, not UI ones.

And that's just one example.