One tends to think of parsing/compiling as a fairly esoteric skillset that a relatively small number of programmers ever actually need at their jobs, but it always makes me glad to see examples like this where a little DSL was a genuine boon to productivity in a real product. Once you know how to do it, you start to notice more and more little opportunities where it could be useful.

This part from the blog post kind of confused me a bit, though.

"The promise of Tailwind UI is that it's just a code snippet"

Am I the only one who never looks at the code snippets/tab for Tailwind UI, and instead jumps straight into inspect element? As blueprints the components are great, but I almost always want to make some small tweaks or changes to fit my application. Are there other people out there actually copying/pasting the snippets as they are?

<Button className="bg-gray-100 rounded-full flex" ...

How do you remember the names of all your classes? Should your IDE know about these classes? Can you autocomplete class names? Where's the import statement for these classes so you know where they're defined and what they do. There's a better way:

Use site-wide themes (Objects with keys like colors.heading.primary having value '#000') and withStyles[1] and React.PureComponent[2]. Having your React component render the same result given the same props and state makes things so much easier to work with. Also, the compiler knows about your theme so your IDE helps auto-complete and makes sure the style you're using is actually defined.

[1] https://github.com/airbnb/react-with-styles

[2] https://reactjs.org/docs/react-api.html#reactpurecomponent

I often wonder whether we need yet another UI framework implementation? I touched on this in my post a couple days ago: https://williamhoyle.ca/blog/2021/vue-has-too-many-ui-framew...

To summarize:

We have 20+ UI frameworks written in Vue. Surely there's enough common ground/code to combine the implementation details for all these common components. For example, OP mentioned the complexities of implementing a modal with some corner cases for 'ESC' behaviour. This is a universal concept whether you're using WidgetUI or TailwindUI. How many times are we going to re-implement a modal/button/dialog/menu?

We have to learn another set of APIs, props, component names, etc... Of course, no one is forcing us to use this. But it seems like we're going in circles re-implementing the same UI patterns over and over again.

I wish we could standardize on a library. Imagine just pulling in GenericUI and sprinkling in your CSS of choice (e.g. tailwindCSS, Bulma, Material, etc...).

I'm a Vue guy, but I think my argument still stands for the React ecosystem.

Adam's (author) podcast Full Stack Radio is useful like this too [1].

[0] https://www.w3.org/TR/wai-aria-practices/examples/menu-butto...

[1] https://fullstackradio.com/

I even built something like Tailwind UI but for Chakra (link is in my bio if you want to check it out)

One year ago I had to do something similar and used Web Components (https://www.robinwieruch.de/react-web-components). Did you consider using Web Components or a Web Components library such as lit-html in the first place?

I assumed that I would use Tailwind UI's HTML for these and write vanilla JS for interactivity, but now I am rethinking, especially having read this quote in the article: "If we tried to write it in custom vanilla JS, well we'd be making it harder for literally everyone".

So given this announcement, in my situation would you recommend against vanilla JS, and instead to adopt one of React or Vue?

    <Menu.Items className="absolute mt-1 right-0">

    <Menu.Items absolute mt-1 right-0>

Personally, I write CSS this way:

1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames.

Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tailwind does) but it should be "p.author-role".

In my case the classname is semantically descriptive whereas Tailwind is not. In my case you just need to update the CSS and in the case of Tailwind you need to change your HTML and then probably also create a new CSS class.

But still, ideally, you'd simply select it like this:

The author name:

    figure.author figcaption h5 { ... }

    figure.author figcaption h6 { ... }

1. @apply as a JS function that I can use in CSS in JS.

2. Some way to override existing Tailwind classes with new ones (ex: Generic Button => Specialized Button => Unique Button).

Yes! (https://marketplace.visualstudio.com/items?itemName=bradlc.v...)

Although I wouldn't mind an array instead so I can use the typescript typechecker.

Having IDE autocompletion (or even TypeScript integration) would be really nice. I'm sure there's plugins for many IDEs or editors that can do that, though.

I currently have a tailwind project that's around twelve months old. I'd like to add a dark theme.

Normally - in a CSS, SCSS, PostCSS project - this would consist of adding a media query overriding a handful of color variables.

Using tailwind (which has 'inbuilt dark mode support') I have a few thousand colors spread around the project and I have to modify them all. Additionally by having a giant palette of named colors, we have, for example, multiple occurrences of our active color as `blue-400` and `blue-500` and `blue-600` rather than a single `var(--active-color)`.

Tailwind is easy to start but hard to maintain and extend.

Its good for a prototype or small landing page.

I would never use it for long term project where you need to maintain and extend your features a lot.

You don't.

https://tailwindcss.com/docs/extracting-components

Because the web wasn’t designed for applications UI interfaces (hence the CSS grid which landed only in 2017), so it lacks basic primitives and behaviors that are then re-implemented slightly differently by different people. On the contrary, a UI framework designed for this such as the Windows Forms on Windows desktop is still very usable (and used) to make applications, 20 years after its release; and is only concurrenced by a single newer framework (WPF) which actually brings a lot of improvements on the table.

Actually the web does it half-way: there are a set of common elements (input text, button, etc.) but some useful components are missing, and some of the existing one are hard to style. This support should be added in browsers, then custom code wouldn’t be needed anymore.

So we end up with 20x libs all doing roughly the same thing, sometimes badly.

This one doesn't seem like the typical Munroe +1, because it's not trying to rule them all, just put a visually unopinionated base in place with the tricky, boring stuff handled. It kinda feels like other libs are doing too much in any case.

That's exactly what the tailwind people built in Headless UI: "a library of JS components that abstract away all of the keyboard navigation and accessibility logic without including any design opinions"

Those things alone are reason for never using Chakra for anything serious as these are actual reasons your product/saas/whatever is at a higher risk of failing.

And that's just apart from the fact that the components are not allowing easy overriding, theming is a mess (especially if you want Typescript support again for your custom variants) and it's sometimes buggy with the way DOM events are handled (the checkbox being the biggest offender). At some point the frontend also randomly crashed for me because of the Popover component and it's usage of Popper.js

Third paragraph of the article

Headless UI is some of the nicest React components I’ve worked with via interop, and to me it’s really valuable that they don’t come with an opinionated way of styling them.

"Shoot, was this 13px padding or 14px padding on the other page?" Don't worry about it, just use "p-4, p-6, etc.". Thinking in these terms becomes really powerful.

Another great thing as that you just simply don't have to think about what to name things! I find that so liberating, to be honest, and I don't have to keep switching back and forth between my markup and my css. I don't have to worry about coming up with semantically descriptive names. I just use "text-gray-500". Was this .authorrole? Or was it .authoremail? Hmm, now I want to display an author nickname. Do I just repeat "authorname" class? I find it so freeing to basically not have to worry about this stuff at all.

That said, I’m surprised by this:

“Only when you have troubles selecting an element based on its position in your DOM you should choose a classname”

Certainly if you have knowledge of the exact DOM structure in advance, and high confidence that it will never be substantially changed, this is workable. But in many cases, having the CSS care about the DOM structure produces way more pain than the ergonomics of tailwind do. At least in the kind of code I’ve worked on where components are reused all over the place and sometimes rearranged by authors directly in a CMS. Or just having DOM reorganized because something is added that requires an extra wrapper & then all the CSS selectors are nested wrong. Or whatever.

Anyhoo. I don’t love tailwind, but I think it’s fine. Far worse things have happened to web dev. It seems like you have a problem with utility CSS, which tailwind takes to the extreme for sure.

Also, side note - having headings in a figcaption like that seems semantically incorrect.

Tailwind and other functional frameworks use classes for abstraction, which unlocks media queries, pseudo selectors, and many other CSS features.

Plus Tailwind's build system generates styles according to your config, which is sort of what distinguishes it from other functional frameworks.

"Semantically" descriptive could mean any number of things. In this case, it seems to mean: name your class according to what it's supposed to do, which is nice in theory, except that it hides the relationship between the markup and CSS. A well-prepared stylesheet is nice, except when the markup doesn't match what it expects.

In Tailwind, the class names themselves are "semantically" descriptive because they do exactly what they are supposed to do. There are no hidden abstractions.

It's not, because there's a system to it. With Tailwind you pick specific values. Inline styles let you specify any value.

> It should not be ".text-gray-500" (like Tailwind does)

This is fair. I'd never considered that specifying the actual color in the class name would be problematic, but another thread pointed out that it makes theming (such as dark mode) difficult.

> 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames.

I'm sure this works great when there are a small number of people working on styles. When there are many, however, I've found that the cascade often results in styles overriding one another, and needing to introduce more specificity to fight it, in an endless cycle.

Obviously people should write better CSS to avoid that. Which is actually what Tailwind is, I think.