Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS's problems are Tailwind's problems

colton.dev

Post reply on HN
Print view View original

91–100 of 179 posts

Re: CSS's problems are Tailwind's problems

#91

Post by mejutoco »

micromacrofoot wrote: post #6
lenkite wrote: post #4

If you go even minimally outside the beaten path, the tailwind CSS declarations can mutate into a frankenstein monster that makes regular CSS look like a friendly, cute koala Example: https://www.nikolailehbr.ink/blog/realistic-button-design-cs... shows an "old fashioned", 90's are back-in-vogue, 3d button. Tailwind CSS for it becomes After I got eye-strain and headaches after taking over maintenance of a tailwind ba…

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

There was a time when not having css and html completely separate was considered sacrilege. And having html in javascript would have been a mortal sin.

Eons ago I was at a job where we dynamically generated css on the server (php in that project). Anyone would have said: what about separation of concerns? Now everyone says it is best practice to have components with css, html and (gasp) Javascript all in one unit, because someone, for ex. Facebook said it (React). And the truth is it is very useful, and it is another way to structure frontend code.

My point is: it is a spectrum and it can be useful to change the styling right there in the browser inspector. That works with tailwind the same as css. And with components, you can hide the repetition, although the browser will still have the repeated classes. Is this better than having css on another file with maybe some unused classes? I have done both and I can see each has pros and cons.

Re: CSS's problems are Tailwind's problems

#93

Post by shkkmo »

dontlikeyoueith wrote: post #59
wwweston wrote: post #41

Earlier quoted context omitted.

You’re correct in the sense that they’re both big noisy blobs that dilute semantic/functional signals. You’re neglecting the design system work that goes into tailwind classes. I don’t particularly like its choices (and generally consider tailwind to be a minimal local maximum for a set of tradeoffs deserving of faint praise), but they’re something, and in an engineering culture that won’t adopt a better mindset or b…

> 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 took a sec but I parsed "a minimal local maximum" as "from the set of all local maximums, this local maximum is near the bottom." Thus it is a local maximum, so any small change produces a worse result, but it is one of the worst local maximums you could have found.

Re: CSS's problems are Tailwind's problems

#94

Post by mdhb »

pyman wrote: post #76
jakelazaroff wrote: post #49

Earlier quoted context omitted.

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?

I think you should find a new job.

Re: CSS's problems are Tailwind's problems

#95

Post by nine_k »

dontlikeyoueith wrote: post #59
wwweston wrote: post #41

Earlier quoted context omitted.

You’re correct in the sense that they’re both big noisy blobs that dilute semantic/functional signals. You’re neglecting the design system work that goes into tailwind classes. I don’t particularly like its choices (and generally consider tailwind to be a minimal local maximum for a set of tradeoffs deserving of faint praise), but they’re something, and in an engineering culture that won’t adopt a better mindset or b…

> 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.

Re: CSS's problems are Tailwind's problems

#96

Post by 9dev »

kccqzy wrote: post #40
mootothemax wrote: post #26

Tailwind is magical to me for one reason alone: I can now design. As someone who spent 20+ years as a jack-of-all-trades / full-stack developer, specialising in back-end and database skills, this has largely been... confusing. Before, I couldn't even make plain text work. Totally hopeless, I didn't have the eye for things. Now though, now I help my kids lay out their homework to be more visually pleasing. It's bizarr…

A decade ago Bootstrap helped a generation of programmers who don't know how to design make pleasantly looking websites. I fail to see how Tailwind is better suited to that task than Bootstrap.

With bootstrap, there was a fixed set of components to pick from. For a lot of things, there were no suitable components, so people used those that they had for everything else, kind of like designing furniture in Minecraft with blocks. This makes bootstrap interfaces bland and overly similar, in a way that Tailwind doesn’t: its design system is fundamentally based around design tokens arranged in sensible steps, not full components. That allows for a lot more flexibility and stylistic control.

Re: CSS's problems are Tailwind's problems

#97

Post by exiguus »

I agree. You can also use Tailwind in CSS modules or in SASS, or create your own CSS helper classes. There are many tools available that merge and allow conditional CSS classes. Basically, you can use the same tools as in vanilla CSS to organize your code.

If you use any component library, most of your CSS should be within the component library, not in your application. Components can have variants, such as primary and secondary buttons, for example. This adheres to the DRY principle. Your application can also have reusable components, which helps minimize the use of CSS and HTML. This adheres also to DRY. You can also build your own Component-Library.

You can apply the same programming principles and organizational patterns to HTML and CSS as you would to any other code. This becomes much easier if you separate the view from the rest of the application.

Re: CSS's problems are Tailwind's problems

#98

Post by tptacek »

Early in the article, the claims is made that Tailwind has "become the default styling solution for all modern web development despite taking each and every one of these problems, exacerbating them, and applying them to places that didn't have them before". Later, the case is made that this happened because Tailwind offers a single configuration file. How true does this sound? How little credit does it give to the huge number of front-end teams that have adopted it?

Re: CSS's problems are Tailwind's problems

#99

Post by dsego »

cogman10 wrote: post #20
mohsen1 wrote: post #10

Earlier quoted context omitted.

I used to be against Tailwind. Now that I've used long enough I can tell you that code is perfectly fine. I can read it and easily modify it. You can comment it out if you care After

Reading though this, I really have to wonder how this is better than After Why make a bunch of css classes when it looks to me like the "style" will be roughly the same amount of code and readability.

The style prop doesn't give you a design system, it's just raw values. Maybe you could use something like open props though.

https://open-props.style/

Re: CSS's problems are Tailwind's problems

#100

Post by Alupis »

squidbeak wrote: post #61
Alupis wrote: post #32

Earlier quoted context omitted.

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…

There's a big difference between using utility classes for utilities and using utility classes for everything.

Honest question... why?

Can you tell me, without looking at the implementation, what effect `btn-atc-primary` applies when the user hovers? No... you cannot.

It's less important to have "clean" looking markup than it is to be unambiguous in intention and implementation. If you read a component that uses Tailwind classes, you know - without any doubt - what it does and what it looks like. That's pretty cool...

Post reply on HN