4 ms·

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 inte

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?

CGamesPlay 6y ago
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.
savanaly 6y ago
Tailwind itself has this [0] to say about inline styles vs utility classes. [0] https://tailwindcss.com/docs/utility-first#why-not-just-use-inline-styles https://tailwindcss.com/docs/utility-first#why-not-just-use-...
jozzy-james 6y ago
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?
earthboundkid 6y ago
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".
string 6y ago
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.
- justanotherhn 6y ago
  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.

CGamesPlay 6y ago

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.

savanaly 6y ago

Tailwind itself has this [0] to say about inline styles vs utility classes. [0] https://tailwindcss.com/docs/utility-first#why-not-just-use-inline-styles https://tailwindcss.com/docs/utility-first#why-not-just-use-...

jozzy-james 6y ago

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?

earthboundkid 6y ago

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

string 6y ago

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.

justanotherhn 6y ago
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.