Comment by hospadar | Hacker News Reader

Comment by hospadar | Hacker News Reader

Parent Full thread

Genuine question, I'm a dev, but primarily backend and all my frontends are internal/chunky/it doesn't matter

I usually do 2 things when styling my crummy internal sites: a) manually write semantically-named classes for things that need it ("help-text", "external-link") and b) just in-line styles for everything else (esp. when a style really only applies to one element, or is intimately related to important layout considerations).

It seems to me that css classes which contain styling info in their name (h-32, font-semibold, text-cyan-600) aren't really any better than just in-line styles, and in fact maybe worse because they [seem to me] to just be an alias [which I have to learn, and will forget later] for a css style. Wouldn't it be simpler to just inline the style?

So my question is: what's the real benefit of this kind of css framework? What are the scenarios where it really helps to do styling this way? Is it just a performance thing? Is it about streamlining a dev workflow in some way that I don't get?

It helps streamline the dev workflow, absolutely. At a very basic level, it's much faster for me to write "p-4" than "padding: 1rem;".

A big benefit I see is the constraints it introduces. If another developer comes along, they know there are a few options for padding. Rather than guessing and setting some pixel value (or should it be in em, or rem?) or having to refer to other code or documentation, they can just look at a design document and say "that looks like a p-4", done.

Tailwind also makes things much more flexible than using inline styles: I can add a brand colour to my Tailwind configuration, and I immediately have utility classes available for text, background, fills, hover and focus states, etc. I can update one hex value rather than refactoring every inline style in my app. You could do this with custom classes, but frameworks like Tailwind mean I can hire a new developer and they don't have to look through a stylesheet and memorize potentially hundreds of style definitions and class names. I think this standardisation can be very useful.

Bingo! There is really no reason not to use it considering everything you just described, I don't know why people in this thread have such strong opinions on this? Maybe it's from years of seeing the new "fads" which repackage old, stable solutions and call them a new thing. I have yet to read a comment on this thread which makes a good argument to not use Tailwindcss.

There might be more, but the first that comes to mind is "snapping". To pull from your example, `h-29` through `h-31` don't exist, meaning you have fewer options and will settle on one of the standardized heights. Similarly, `cyan-501` to `cyan-599` don't exist, so you don't accidentally settle on a slightly-different shade.

Tailwind itself has this [0] to say about inline styles vs utility classes.

[0] https://tailwindcss.com/docs/utility-first#why-not-just-use-...

Naming the classes forces consistency (cyan-500, not a random number you could get wrong) and works with media queries. FWIW, the Tailwind devs say you should just use an inline styles for one off things like "this SVG needs to be pushed 41px off baseline".

text-red-500 isn't the same as color=red, and you can override which shade of red that is (or make it green/brown/whatever...tho that would be silly). but you can also define brand-centric names for stuff and they apply to anywhere you'd be able to use a color (text, border, shadow, etc). there's also the notion of having a design system, rather than a prescriptive framework...tailwind comes with some sensible defaults on these things, but it's built in a way that you can override it all to suite your org's look and feel.

with that said, it's an internal tool - who give a hoot?

Reply on news.ycombinator.com