[northern-lights]

It seems to be in Google's interest to keep Tailwind CSS afloat.

Tailwind CSS is alive -> New / existing projects keep using Tailwind CSS -> more code for Gemini to train upon -> better and fancier UIs being created through Gemini -> popularity and usage of Gemini doesn't go down

Of course this applies to any other LLM provider too but I guess Google saw this opportunity first.

[spankalee]

I think it'd be better for AI and web dev if AIs generated real CSS instead.

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.

[spockz]

I really don’t understand this idea that seems to be prevalent to let the LLM generate everything from scratch instead of using existing battle tested frameworks. Be it for css or backend code.

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.

[spankalee]

CSS simply doesn't need a framework - there's no "from scratch". For humans or LLM authors.

Tailwind is a lot of overhead conceptually and tooling wise to just not have to write classnames, and it's actually anti-modular.

[AltruisticGapHN]

That's not the full picture.

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.

[vehemenz]

Can you explain? Tailwind massively reduces overhead for abstraction, classing, documentation, and maintenance.

[wrs]

AFAICT, Tailwind is largely (not entirely) a different, shorter syntax for writing inline styles. (E.g., "class: 'bg-white'" = "style: 'background-color: white'".)

If you've rejected structural CSS to begin with, I sort of get the point that it saves a lot of typing; otherwise I don't see how it helps all that much over SASS or just modern plain CSS.

[rvnx]

Tailwind is a dirty hack, normally you are supposed to declare a class, which you apply to items of the same concept. This is the cause for CSS to exist.

Front devs got lazy, and started writing for each element, position: absolute; left:3px, top:6px, color:red;...

You could write <font color="red">Hello</font> this would be similar "cleanliness"

[baq]

Supply chain risk is real. Granted in CSS it’s probably less of a concern than in code, but it cannot be denied. LLMs make the proposition of supply chain reduction not irrational at the very least.

[barnabee]

I’ve had zero problems getting Claude to generate CSS.

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.

[DoesntMatter22]

Totally agree with this, and I think it's what will likely happen. IMO Tailwind got to the point where you are adding dozens of classes to the tag and it gets a little unwieldy. There are some options to get around it but if AI just does't need it it's even better.

[groby_b]

There's nothing stopping you from requesting the AI write bare CSS. They're pretty decent at that too. And feed back screencaps, ask it to fix anything that's wrong, and five iterations later you have what you want. Just like a developer.

Bonus point: It'll appreciate one of those "CSS is awesome" mugs, too.

[blacksmith_tb]

I'm not a fan of Tailwind, but I can see that it's probably reasonable for code gen to be able to write / extend projects that use Tailwind, since it's in pretty widespread use. For a new project, maybe it could ask if you want to use Tailwind or just keep things vanilla?

[vehemenz]

Tailwind is almost too simple to bother using an LLM for. There’s no reason to introduce high-level abstractions (your “real” CSS, I imagine) that make the code more complicated, unless you have some clever methodology.

[gedy]

I don't really like Tailwind, but it's a really good fit for LLM tools because there's basically no context needed like you get with normal CSS inheritance, etc. What you see is what you get.

[nosefurhairdo]

AI is great at any styling solution via system prompt + established patterns in codebase. Tailwind is just slightly more convenient since it's consistent and very popular.

[YetAnotherNick]

The thing is LLM generate token by token and if you have to write entire css before writing the html, the quality could be worse.

[derefr]

You could prompt the LLM to define styling using inline `style` attributes; and then, once you've got a page that looks good, prompt it to go back and factor those out into a stylesheet with semantic styles, trading the style attributes for sets of class attributes.

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.

[slashdave]

The problem is training data. How many modern web sites use raw CSS?

[barnabee]

Enough that in my experience Claude is great at it and there’s even less justification for Tailwind if you’re using AI.

[Klonoar]

Counter-argument: the cascade in CSS was a massive design mistake and it shows even more in this particular case.

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.

[spankalee]

I haven't seen cascades be a problem since the days of monolithic, app-wide stylesheets, and no project I personally know of works that way anymore.

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.

[Klonoar]

> Just about everyone uses component-specific styles

Yeah.

At which point you can simply use e.g Tailwind.

[Lalabadie]

What component-specific styles look like:

class="menu-item"

Styles-in-HTML (Tailwind):

class="m-4 mb-2 p-2 border border-radius-sm border gray-200 hover:border-gray-300 font-sm sm:font-xs [...]"

You can be completely insensitive to or unbothered by the difference, but that doesn't mean they're equivalent.

[Klonoar]

I'm not saying they're equivalent. I'm saying that the latter is better, especially in the context of reviewing LLM output.

With the former, I need to cross-reference two different stacks (HTML and CSS) and construct a mental model every time I move between components. With the latter, I can simply look at one output (HTML) and move on with my life, knowing that the chances of conflicts/issues/etc are fairly limited.

You guys are advocating for keeping the semantic separation that we originally aimed for with HTML/CSS, but in an LLM world this is yet another distinction that probably "does not matter".

[spankalee]

No, because many components have internals that need to be styled consistently with parts of other components.

With plain CSS components can easily share styles and use them by adding the correct class name to elements.

With Tailwind you have to copy your list of super fine-grained classes to each component, and try to keep them in sync over time

[eterm]

If you're arguing down that route, LLMs can bulk-apply style attributes exactly where they're needed. Every element precisely described, no need for CSS and style-sheets at all.

[Klonoar]

And then you'd wind up with a needlessly noisy approach, and then you will reach for Tailwind to do basically the same thing but in a more terse manner. ;P

[politelemon]

I'm not really seeing or buying this connection. LLMs are capable of generating CSS which is untethered to finances. If tailwind went away it would be in Gemini's interest to not generate it.

[8note]

another guess could be "gemini tends to write code using tailwind css, so if it goes down, gemini will be writing a lot of out of date code"

[_puk]

I think that keeping tailwind alive means that Gemini Studio:

* Likely gets preferential access to new features and changes in tailwind, keeping it cutting edge

* Keeps a framework alive that Gemini is already good at

If a new framework becomes popular then the amount of training material / material already trained into the model essentially starts from 0.

The mature Frameworks that had plenty of openly available data to train on before everything became locked away are the ones we'll be running with for the next few years. It makes sense to keep it alive.