The supposed difficulty of tracking from elements to classes to rulesets is something that AIs can easily handle, and being able to change a ruleset once and have the update apply to all use sites is really good for AI-driven changes.
Plus, humans and AIs won't have to wait for Tailwind to adopt new CSS features as they are added. If the AI can read MDN, it can use the feature.
Good modular design of software and separation of concern are still important for debugging and lifecycle. For (instructing) the llm it will also be easier if it uses frameworks as the resulting code of the project itself will remain smaller, reducing the context for both llm and human.
Tailwind is a lot of overhead conceptually and tooling wise to just not have to write classnames, and it's actually anti-modular.
If you're a senior CSS developer you will invariably reach a point of using "object oriented CSS" which is where you combine classes to an effect.
At that point you're not far off Tailwind. TW just took it all the way.
I generally ask for the following, from scratch for each project:
- A theme file full of variables (if you squint this actually looks a bit like Tailwind)
- A file containing global styles, mostly semantic, rather than just piles of classes
- Specific, per component styles (I often use Svelte so this is easy as they live in the component files and are automatically scoped to the component)
IMO there’s even less need for Tailwind with AI than there was before.
When I see people talking about how good AI is with Tailwind it just feels like they’re lazily copying each other without even trying to avoid unnecessary complexity.
Bonus point: It'll appreciate one of those "CSS is awesome" mugs, too.
Or you could tell the LLM that while prototyping, it should define the CSS "just in time" before/after each part of the HTML, by generating inline <script>s that embed CSS stanzas as string literals, and which immediately inject those into the document using CSSStyleSheet.insertRule(). (This can, again, be cleaned up afterward.)
Or, you can keep your CSS and your HTML separate, but also keep an internal documentation file (a "style guide") that describes how and when to use the CSS classes defined in the stylesheet. This is your in-context equivalent to the knowledge the LLM already has burned-in from training on the Tailwind docs site. Then, in your coding agent's instructions, you can tell it that when writing HTML, it should refer to the "style guide", rather than trying to reverse-engineer the usage of the styles from their implementation in CSS.
With LLM-assisted development you spend more time reading and reviewing the generated code. The cascade in styles is nowhere near as readily apparent as something like Tailwind.
Just about everyone uses component-specific styles with a limited set of selectors where there are very few collisions per property, and pretty clear specificity winners when there are.
If the alternative to the cascade is that you have to repeat granular style choices on every single element, I'll take the cascade every time.
Yeah.
At which point you can simply use e.g Tailwind.
