Live data from Hacker News

CSS's problems are Tailwind's problems

colton.dev

71–80 of 179 posts

Re: CSS's problems are Tailwind's problems

#71

Tailwind was better for me before AI, and it’s WAY better for me with AI. Claude can write CSS and HTML together in my templates, without needing to reference back and forth. It’s very, very good at writing tailwind. Perhaps Tailwind is the worst of all your worlds, but it’s better than Bootstrap and Bulma and all the other stuff I genuinely tried. I don’t get why people can’t just let Tailwind users be happy. Like,…

yeah I was going to say this. AI is incredibly good at writing tailwind. Part of it is probably exactly the colocation issue. Context windows are precious.

Also, Tailwind is included in Claude's artifact/preview system and Claude is prompted to use it by default. Hard to beat that compared to "oops, pls implement it in Bootstrap" and then copying the output to JSFiddle with Bootstrap loaded just to see it. :(

I don't use Tailwind but what usually happens is that it creates a great Tailwind mockup that I'm happy with, and then I tell it to port it to Bootstrap (which involves a mix of Bootstrap classes and custom CSS) and it always looks worse, heh.

So Tailwind + LLM support is pretty big advantage.

Re: CSS's problems are Tailwind's problems

#72

Since Tailwind looks obviously bad on first pass with all the class spam, I'm more curious to see someone steelman Tailwind. I have some ideas, like how the dead code elimination + granular but consistent classes lets you build novel components that are still consistent with your UI which might be essential for making a 3rd party component library work. I've been using Bootstrap since it came out 15 years ago but it…

I think the best argument for Tailwind still is the blog post that the creator wrote to promote the idea (it was before the first alpha release iirc):

https://adamwathan.me/css-utility-classes-and-separation-of-...

Everything is a tradeoff. I don't miss Tailwind in my day job, but I would certainly if I had to work on the type of project where I last successfully used it.

Re: CSS's problems are Tailwind's problems

#74
post #56

I use tailwind on all of my projects now and like it. I've used a lot of the css fads of the last decade (css in js was the worst which ironically is what the author recommends) and tailwind is the most ergonomic for me -and apparently most web devs considering how popular it is. "Did you really say bundler?" If you dont use a bundler this is a fair point. But I'm confident you do use one so adding tailwind is ~3 lin…

I should have phrased this better. My point isn't to say that a bundler is a bad idea (I of course use bundlers on most projects at this point). My point is to say that a library that feels like it does so little still requires a bundler feels wrong.

Re: CSS's problems are Tailwind's problems

#75
In regards to developer experience, UnoCSS https://unocss.dev/ has a better implementation of tailwind for the JS ecosystem. It uses the build step so you can write code like

  hover:(bg-red-500 text-white font-bold)
and it compiles to separate classes.

It's very configurable for better or worse, and the VSCode extension is better too.

Re: CSS's problems are Tailwind's problems

#76

Earlier quoted context omitted.

Is that more or less verbose than button { position: relative; cursor: pointer; overflow: hidden; border-radius: 0.375rem; border: 1px solid #0a0a0a; background-color: #171717; padding: 6px 12px; color: #f5f5f5; box-shadow: inset 0 1px #525252, 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1); transition: all 150ms cubic-bezier(0.4, 0, 0.2, 1); } button::before { content: ""; position: absolute; inset…

It's not quite apples-to-apples because the Tailwind code is using design tokens and the CSS is not. You should (for example) replace the long `box-shadow` value with `var(--shadow-md)`. Anyway, to me this question is kind of like asking "Is it easier to break your writing into paragraphs, or write everything in one long block?" Like, what would you think if I formatted my comment like this? > It's not quite apples-t…

This isn't something a web developer should be doing in 2025. The styling should be generated by the software used to design the UI.

Why aren't the companies building design tools solving this?

Re: CSS's problems are Tailwind's problems

#77

Tailwind was better for me before AI, and it’s WAY better for me with AI. Claude can write CSS and HTML together in my templates, without needing to reference back and forth. It’s very, very good at writing tailwind. Perhaps Tailwind is the worst of all your worlds, but it’s better than Bootstrap and Bulma and all the other stuff I genuinely tried. I don’t get why people can’t just let Tailwind users be happy. Like,…

yeah I was going to say this. AI is incredibly good at writing tailwind. Part of it is probably exactly the colocation issue. Context windows are precious.

AI was incredibly bad when Tailwind v4.0 was released. All the models trying force me to use the config file I did not want to and so on, every time.

Re: CSS's problems are Tailwind's problems

#78

It works much better with AI though, which is really all that matters at this point

Is that true though? Every time i tried to get Sonnet to write out any actually complicated layout/component, I ended up with a novel of classNames with a ton of duplication and useless additions. Those are very hard to spot inside a soup of tailwind classes, whereas I can see them immediately in a nicely laid out stylesheet. This happened extremely often when I tried to iterate with Cursor/CC on the given design, instead of giving up immediately after it failed to one-shot it.

Re: CSS's problems are Tailwind's problems

#79

Earlier quoted context omitted.

Is that more or less verbose than button { position: relative; cursor: pointer; overflow: hidden; border-radius: 0.375rem; border: 1px solid #0a0a0a; background-color: #171717; padding: 6px 12px; color: #f5f5f5; box-shadow: inset 0 1px #525252, 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1); transition: all 150ms cubic-bezier(0.4, 0, 0.2, 1); } button::before { content: ""; position: absolute; inset…

It's not quite apples-to-apples because the Tailwind code is using design tokens and the CSS is not. You should (for example) replace the long `box-shadow` value with `var(--shadow-md)`. Anyway, to me this question is kind of like asking "Is it easier to break your writing into paragraphs, or write everything in one long block?" Like, what would you think if I formatted my comment like this? > It's not quite apples-t…

Most people use Tailwind with components, and so when you talk about breaking things out into paragraphs, that would be the equivalent.

Sure that html looks a bit messy, but once you write it once you're never looking at it again. In your view files you're just writing.

  Click Me!
Or perhaps injecting variables etc.

  Click Me!
I'm not really trying to argue that Tailwind is better or worse, I'm just saying it's a valid way to do things and there's nothing inherently wrong or flawed with it.

Re: CSS's problems are Tailwind's problems

#80
I'm a bit of a luddite with CSS. I learned BEM about five years ago and I've more or less always stuck to component scoped CSS files.

Sometimes I use CSS-in-JS if a component system demands it, like Material. I don't mind it as much as others do, I like that there's no CSS concatenation weirdness. But otherwise I feel quite happy with a component file and a style file.

For Tailwind fans (or even detractors), what's the main benefit I'm missing?

Post reply on HN