styletron VS headlessui

React is pretty much its own language at this point. With J/TSX. Not even CSS is immune to react's approach of "what everything was proprammatically generated divs?", case and point https://www.styletron.org

Some technical thoughts as someone who could care less about fanboyism:

- One point where atomic CSS frameworks are supposed to shine over conventional CSS is bundle size, since they (at least the good ones) compile to only a single rule for any used value, rather than potentially repeating rules for semantically different classes.

- Another point where atomic CSS frameworks shine is just sheer volume of banging code out. When the bulk of your output is visual, mastering tools based on shorthands like tailwind, emmet, etc can feel very productive.

- Purely atomic CSS frameworks can make some workflows more difficult, e.g. by having too granular call sites and not allowing "let's see what happens to the overall theme if I do this design change" iterative style of work, or because workflows that edit CSS on the fly via browser devtools can no longer be used to limit impact within semantic lines (e.g. "I want to change padding only on buttons, without breaking everything else that happens to depend on the same padding value"). There are both design-oriented and debugging-oriented workflows that are affected in similar ways.

- You generally don't get visual regressions at a distance w/ atomic CSS. This matters at organizations where desire for pixel precision and simultaneously fickle design teams are the norm. But conversely, "can we just change the font size to be a bit bigger across the site" can often run into issues of missed spots. On a similar note, designs may become inconsistent across a site over time due to the hyper local nature of atomic CSS oriented development.

- Custom rules may as well be written in APL[0]; they usually aren't documented and it takes a "you-gotta-know-them-to-know-them" sort of familiarity to be able to work with them (or get back to them after a while).

- There are some tools that mix and match atomic CSS with other paradigms. For example, styletron[0] can output atomic CSS for the bundling benefits, but looks like React styled components from a devexp perspective, and has rendering modes that output traditional-looking debug classes for chrome devtool oriented workflows.

The main theme to be aware of: proponents rarely talk of maintenance, so beware of honeymoon effect. Detractors often omit that traditional CSS (especially at scale) also requires a lot of diligence to maintain. So think about maintenance and how AOP[1] vs hyperlocal development workflows interact with your organization's design culture.

[0] https://www.styletron.org/

[1] https://en.wikipedia.org/wiki/Aspect-oriented_programming

It is created, managed, and utilized by Uber. It includes a wide range of attractive components, with accessibility as the top focus. It is quick since it is built with the Styletron engine. Style overrides can be used to tweak themes, but in my experience, I've never required them because the design vibe they're trying for is precisely what I want.

[0] https://www.styletron.org/ [1] https://baseweb.design/blog/getting-started-with-styletron#getting-started-with-styletron

When we created the library, we were using styletron for our styles, and we wanted to bind the breakpoints we defined in @blocz/react-responsive with the breakpoints used for our styles.

Catalyst is a comprehensive, fully componentized UI kit for modern React projects, built on the next generation of Headless UI. With Catalyst, you can create a custom set of components to use and reuse in your projects.

And that is why I was looking for a UI library that would deliver these things for a long time and today I am happy to announce that I have found it! It is Headless UI by the Tailwind Team.

Headless UI provides a suite of unstyled, fully accessible UI components perfect for developers who want full control over their interface design. It's a developer's canvas, offering the foundational parts needed to build a user interface without dictating the aesthetics, making it ideal for those who love to integrate with Tailwind CSS. With https://headlessui.com/, you can ensure that your applications are inclusive and easy to use for everyone, while also maintaining the freedom to craft a unique look and feel that aligns with your brand or style guidelines.

GitHub stars: 22.5k GitHub link: https://github.com/tailwindlabs/headlessui Documentation: https://headlessui.com/

Website: Headless UI

Few months ago, I discovered project called Headless UI and I instantly liked the idea.

In addition to Tailwind CSS, Tailwind Labs also created Headless UI, a collection of components that work well with Tailwind CSS.

Tailwind - Headless UI

Thanks for sharing! I love projects that reimagine entire ecosystems: there's a lot of value in imagining what could be if we didn't worry about what is.

Some feedback: your comparison of the various ListBox implementations[0] feels disingenuous. I know Vue best, so I looked at that implementation in detail, and it's got a lot going on that you don't attempt to replicate in your version. A few key features that are missing:

* Search—in the HeadlessUI version there are several hundred lines dedicated to making typing work for jumping to specific list items.

* Multiselect—HeadlessUI supports multiple selections, yours does not appear to. Again, this occupies a lot of lines.

* Focus management—HeadlessUI has a lot of code dedicated to smoothing out the focus management. In my testing, your implementation has pretty buggy support for using tab to navigate.

* The HeadlessUI version dedicates a lot of lines to types, where your Nue implementation is dynamically typed. This may be a feature for you, but in my mind those type declarations are doing important work.

* In general, the HeadlessUI implementation tries to be flexible for many use cases [2], while yours only needs to support the one demo list.

You also include this render.ts file [1] from HeadlessUI, which is more part of a bespoke sub-framework used by HeadlessUI than it is a necessary part of any old Vue ListBox implementation. If you're going to count that against Vue, then there are parts of Nue JS that should be included as well.

These kinds of comparisons are most persuasive if you can write all the implementations from the ground up, using idiomatic patterns for each framework and identical feature sets for each implementation. When you do that, it's easy to compare and contrast the frameworks. As it is, it's like comparing a house to a garden shed: yes, you've used fewer lines of code, but it's not obvious to me that that's a feature of Nue and not just a byproduct of a less ambitious component.

[0] https://nuejs.org/compare/component.html

[1] https://github.com/tailwindlabs/headlessui/blob/%40headlessu...

[2] https://headlessui.com/vue/listbox#component-apihttps://head...