5 ms·

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 dec

by jitl 2y ago

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! With tailwind, just add 2 classes, done.

rglullis 2y ago
> With tailwind, just add 2 classes, done. 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.
- jitl 2y ago
  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. ¯\_(ツ)_/¯
  - rglullis 2y ago
    > 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.
    - jitl 2y ago
      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 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.
  - rglullis 2y ago
    > 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?

by jitl 2y ago

rglullis 2y ago

> With tailwind, just add 2 classes, done. 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.

jitl 2y ago
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. ¯\_(ツ)_/¯
- rglullis 2y ago
  > 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.
  - jitl 2y ago
    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 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.
- rglullis 2y ago
  > 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?