CSS's problems are Tailwind's problems • Hacker News Board

Re: CSS's problems are Tailwind's problems

#131

Post by omnimus » Tue, Jul 22, 2025, 7:30 PM UTC

zero_shift wrote: post #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 t…

In my case of many small long running projects with multiple people…

1. Speed - you can get stuff done quickly without making problems globally.

2. Self documenting - both in visibility of html but also because of system/config it forces. People understand to use only values (spacing, sizes, colors) in the config or document that they had to add something and why.

3. CSS specificity is not issue.

4. Performance - straight simple classes are very performant. Complex selectors and pseudo classes can be surprisingly taxing without people realizing it. Thats how functional css started btw

Re: CSS's problems are Tailwind's problems

#132

Post by vehemenz » Tue, Jul 22, 2025, 7:33 PM UTC

nine_k wrote: post #95

dontlikeyoueith wrote: post #59

Earlier quoted context omitted.

> generally consider tailwind to be a minimal local maximum I feel like I've been nerd sniped trying to figure out what you mean by this.

It's the lowest hill in the range of CSS frameworks, it's not reaching the heights of proper semantic CSS, but the valleys of haphazard, unsystematic style attributes are an even lower point.

What do you mean by "proper" and "semantic?" The CSS spec never took much of an opinion on how classes should be organized or mapped to elements in the DOM. It's a technical standard. The way people used to write high-abstraction CSS was completely a cultural convention that, in hindsight, overstayed its welcome.

Re: CSS's problems are Tailwind's problems

#133

Post by jakelazaroff » Tue, Jul 22, 2025, 7:34 PM UTC

coltonv wrote: post #70

dminik wrote: post #53

Earlier quoted context omitted.

I reread the conclusion. I apologize for jumping to conclusions so fast but ... You specify like 4 approaches: 1. Tailwind - apparently awful 2. Regular stylesheets - also not good 3. Inline Styles - some flaws 4. CSS-in-JS - minimal flaws when using vanilla-extract Reading through the article, my first thought was that you really like vanilla-extract. When I got to the conclusion section, and the first line is "I li…

I do think you should look at it further! It's a great library, though I can see why people won't like it for the reasons I mentioned in the article (i.e. having to build and enforce your own constants system). If you are going to use something like Tailwind, you're already okay with putting styles in Javascript and adding a bundler plugin, the two main "leaps" required to use something like vanilla-extract. Since th…

This is subjective but the DX of writing CSS in JS object syntax is absolutely miserable. Here's an example from the website:

    export const myStyle = style({
      display: 'flex',
      paddingTop: '3px'
    });

I would much (much!) rather write normal CSS and have some build process extract the class name for me, like with CSS modules: https://github.com/css-modules/css-modules

Re: CSS's problems are Tailwind's problems

#134

Post by p4bl0 » Tue, Jul 22, 2025, 7:34 PM UTC

I never liked Tailwind. The point of CSS was to separate content and presentation. Tailwind not only goes backward on that but does it a lot worse than HTML did before, because the presentation not only is mixed with HTML but is also just a long random string rather than structured into HTML attributes. It's just like CSS using only style="" attributes, only with a different, almost proprietary syntax that you have to learn on addition to actual web standards.

Re: CSS's problems are Tailwind's problems

#135

Post by vehemenz » Tue, Jul 22, 2025, 7:42 PM UTC

hombre_fatal wrote: post #68

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…

> Since Tailwind looks obviously bad on first pass with all the class spam

Why is "class spam" bad? Argument? Go read the CSS spec. There's nothing telling how developers/designers how they should abstract their classes.

High abstraction classes are, I'm convinced, a holdover of the early days of the web when everyone thought XML and XSLT was going to take over the world.

The great thing about functional CSS (especially Tailwind) is that I can see exactly which styles are being applied, immediately, anywhere I want in the DOM. I don't have to consult a separate stylesheet or refresh my browser. There's no context-switching and everything gets built 3-4x as fast.

Re: CSS's problems are Tailwind's problems

#136

Post by Francute » Tue, Jul 22, 2025, 7:44 PM UTC

vehemenz wrote: post #123

> Tailwind does nothing to reduce the mental load on your developers to understand, read, and write in your codebase. In fact it does the opposite. Your developers are not spared the hassle of learning CSS by instead learning tailwind's abstractions. Developers have to understand not just that background-color is the CSS key to set a background color, but they also must understand that classes prefixed with bg- mean…

But you can achieve the same thing (1:1 style:class mappings without hidden structures) using other libraries, like the ones mentioned here; styled components and vanilla-extract. You can even achieve that natively with web components.

So, I truly agree with this blog post, and I even wanted to rant the same things showing that you should not compare tailwind against classic CSS stylesheets from 2010, but against how different solutions looks like using different tools the community seems to have thrown away or forgot.

And I know is not relevant to your comment, but I will add that "but you will have to maintain more files instead of just a single HTML file" is not a valid argument for me. If that were something good, then just put everything into a single giant server. file + separated lib dependencies.

We want maintainable easy to follow and understand files. Having a clean html with no cluttering + intuitive CSS styles being applied where we expect them and looking exactly as we expect them while reading the html, is the big win for me, and Tailwind definitely does a step back on this, especially when other tools can achieve that. (Lastly, we have set multiple projects with different tools, and the amount of "wtf"s we've seen with tailwind is way higher than just styled components to give one example)

I agree that the only good thing Tailwind achieves, is setting a default convention on having a single config file where you can set everything that you will need on every design across all your html files

Re: CSS's problems are Tailwind's problems

#137

Post by antonio07c » Tue, Jul 22, 2025, 7:47 PM UTC

Alupis wrote: post #32

micromacrofoot wrote: post #6

Earlier quoted context omitted.

I can't believe people find even half of this acceptable, do they never use a browser inspector in their work?

If you write enough CSS for a site... eventually you end up building utility classes anyway. Now, you re-invented Tailwind... but in your own proprietary way that nobody else understands. Tailwind takes the inverse approach. The example posted by the parent above is completely unambiguous - what you see is what you get, and it's done the same way everywhere Tailwind is used. You can read the component's styles and un…

In your example you are creating a class for a single property which is what people are complaining about. I would create a .card class that contains the padding (and all needed styles) and probably use a --site-padding variable.

Re: CSS's problems are Tailwind's problems

#138

Post by yowzadave » Tue, Jul 22, 2025, 7:56 PM UTC

vijivishali wrote: post #81

hbn wrote: post #38

Been using Tailwind since starting my job 5 years ago where we have a ton of webapps standardized on Angular+Tailwind, and you may have to hop into a webapp you've never heard of before to fix a bug. Couldn't be happier with how much easier it is to build and maintain compared to traditional CSS. Many many words I've read trying to convince me why I shouldn't be having a good time using it, yet here I am more product…

I echo this. For all the supposedly bad things it is, Tailwind provides a level of common denominator in a big team still making sure the CSS at the basic level is nice.

It doesn't even require a big team to be useful—I won't remember how I organized a set of styles a few months from now, and having Tailwind require a minimal set of constraints, and keeping the styles easily editable in the place you use them makes things more maintainable over time.

Re: CSS's problems are Tailwind's problems

#139

Post by wwweston » Tue, Jul 22, 2025, 8:03 PM UTC

treyd wrote: post #114

wwweston wrote: post #66

This is a novel take that I think genuinely adds something to tired tailwind discourse: > I think the most important factor in Tailwind's success is that it does one thing very correctly: it demands the developer who installs it set up a config file that lays out all codebase-wide style constants: colors, margin sizes, fonts, border radii, etc. Writing individual styles that do not use a pre-configured constant from…

But this isn't unique or new with Tailwind. SCSS and that family of tools had this 10 years ago.

I think the SCSS and SASS implementations I used 5-10 years back had the capability but didn’t require any set variables, and I think one point of the argument is that this has more benefits than you’d think.

Re: CSS's problems are Tailwind's problems

#140

Post by jumploops » Tue, Jul 22, 2025, 8:21 PM UTC

I hated Tailwind when I first used it.

> (Tailwind) demands the developer who installs it set up a config file that lays out all codebase-wide style constants

> I believe this is where Tailwind has succeeded and other libraries have struggled.

This isn't why Tailwind has "succeeded," in my experience.

Until Sonnet 3.5, LLMs were pretty awful at creating any sort of UI with normal CSS, but were partially usable with Tailwind due to the colocation of styles with elements. Even with Sonnet 3.5+, Tailwind seems to perform better than other CSS solutions (though the gap is getting smaller with each new model release).

The author calls this out, but with the wrong conclusion:

> Lastly, Tailwind has also been buoyed by being by being the default styling that just about any LLM or vibe coding tool will produce [..] Plenty of developers started using jQuery because the first StackOverflow result in their search explained how to solve that problem with jQuery.

Maybe the reason jQuery was so popular wasn't due to recommendations on StackOverflow, but it's prevalence on StackOverflow was due how easy it was to adopt?

Tailwind has "succeeded" for the same reasons it's excelled with LLMs:

- colocation of styles with elements

- decent defaults (i.e. bg-sky-600, font-bold)

- simple solutions to common challenges:

  - responsive design (lg:flex-row) 
 
  - dark mode (dark:text-white)
 
  - conditional state (hover:bg-red-600 focus:outline-violet-500

Obviously, Tailwind, just like other CSS-in-JS solutions has it's problems/limits, but it's easy enough to fall back to normal CSS for these one-off solutions.

I now use Tailwind everyday, and it's no longer the worst thing in the world.