CSS has become more confusing over time, not less confusing, so the upside of a utility class approach like Tailwind is also improving over time rather than decreasing.
Tailwind solves css confusion by presenting a “paved road” for many tasks. Want to do “thing”? Just look up “thing” in the tailwind docs, add “thing-2” to your class, done in 2 minutes. Rather than look up “thing” on google, skim several articles, then write 4-10 lines of CSS, done in 30 minutes.
As CSS has gotten more complexity from new capabilities, solving various tasks with it feels more and more like a research project. Like centering a div vertically and horizontally - there’s now 3-4 generations of solutions for this task:
1. Hacky stuff with position: absolute or floats
2. Flexbox approach. Hope you remember the 6 different attributes you need to set! Oh, there’s a new shorthand for flex now? Cool! More stuff to learn.
3. Grid approach. There are a bunch of different ways to structure a grid centering approach. Hope you remember how grid templates work!
But you can do that with a library of SASS mixins as well.
Going through some of the answers I'm noticing that another "issue" I have with the tailwind approach is that it works by providing a post-processor when in reality most people just need a simple preprocessor and macro system.
Sure? I don’t see how that’s an argument for CSS “being advanced enough” - SASS ain’t CSS.
I like SASS (I wrote a lisp in SASS in 2011 lol) and that’s actually how I think about Tailwind utilities - it’s just using SASS mixins directly in your HTML. I would rather use Tailwind because it will take 1/3 the levels of abstraction, 1/4 the keystrokes and 1/2 the files to do the same job to:
1. Pick a class name (myclass) if people are using BEM or something this requires some algebraic thinking.
2. Write the class in file.scss to define the class and include mixins A, B, C
3. Add class=myclass in my html.
Vs tailwind:
1. Add class=“A B C” to my html.
I don’t really get pre processor vs post processor, it’s a build step to run at some point before I deploy with either tool that will produce some css files. ¯\_(ツ)_/¯
> I don’t really get pre processor vs post processor, it’s a build step to run at some point before I deploy with either tool that will produce some css files.
Not quite the same. If it's only a preprocessor, the tool is only dependent on your styling code. A post-processor needs the whole application.
It's a lot easier to add or remove a pre-processor from your development process, and for those that want to consume your styles it is a lot nicer when you don't have to adopt their tooling as well. E.g, I can create a "utility class library" in SASS, generate the CSS and let people just import that directly into their web pages. Is that possible to do with tailwind?
> I don’t see how that’s an argument for CSS “being advanced enough”
That's a separate argument.
I hear mostly two justifications for tailwind:
1. It is (or used to be) hard to do things in CSS like variables, calculated properties, themes, scoped rules / namespacing. (Pre/Post) Processors are going to be required anyway, so we might as well use Tailwind
2. It gives frontend developers and designers a common language (the utility classes) which makes it easier to establish workflows.
My argument for (1) is that CSS already supports a lot of things that used to require processors, and (2) could be achieved with a simple "library" that could just be imported directly.
I agree neither of those seem like good reasons to pick tailwind.
My take is that it removes needless indirection in any codebase that already has “components” - react/vue/solid/etc, template partials, functions that return html strings, whatever. See comment here: https://news.ycombinator.com/item?id=42804831
For that reason, plus it’s concision, I find it more productive use of time compared to css-in-separate-file.
If you don’t have components for separating semantics from presentation, then tailwind is less a good fit.
A concrete example that seems like a no-brainer to me: let's add a little padding to the top and bottom of an element. "py-2" Done. In CSS, specifying padding (or margins) is 4 values... except I forget which is the first one. And what units should I use... px, pt, rem, em. Inline, same-page style, or an external .css file? If not inline, what should I name the class? Vanilla CSS literally requires 10x more time and mental attention.
> "py-2" Done. In CSS, specifying padding (or margins) is 4 values... except I forget which is the first one.
False dichotomy. You are not stuck between tailwind and "Vanilla CSS", and one can solve the issue you are presenting with any reasonable set of SASS mixins.
Do you have any links describing what you mean? I'm not a CSS guru, and perhaps I know only the "old" CSS. I did recently learn Tailwind and it's way nicer than the "old" CSS.
If modern CSS makes styling as easy as Tailwind does, I'd love to read about it.
Because of multitude of reasons. One of the big ones being never having to search through a style tag or finding a CSS file. 100% of the element styling is described in the element markup.
That is atomic CSS, and it predates tailwind by quite a bit. There is a huge marketing push behind tailwind. If you look into who made it, you'd see it wasn't their first attempt.
Why do you keep saying CSS has “caught up”? Tailwind has always just mapped to CSS, so you’ve always been able to do anything in CSS that you could do in tailwind. What has CSS done that makes you see no value in Tailwind today where you used to see value?
