DEV Community

Discussion on: TailwindCSS: Adds complexity, does nothing.

tofraley profile image
Taylor Fraley

I don't know why you keep saying this is not how Tailwind is intended to be used. The page you linked to is titled "Utility First". I infer that to mean the expectation is you start with utilities, and move to something else if you need it. Practically every word on that page seems to back up that inference.

Further down the page is a section titled "Why not just use inline styles?" which explains what they see as the advantages of utility classes over inline styles. You didn't even acknowledge their reasoning in your article.

The section after that one is "Maintainability concerns". This is where they expressly state that using apply to group styles together is, actually, using it "as intended".

Again, it seems clear to me Tailwind's intention is you would build styles using utility classes first. After some point, they completely expect you to group at least some of those utility classes into a "bigger" class. You seem to think this grouping completely negates the benefits of using utility classes, and that you might as well write it in CSS.

The documentation page that discusses this in particular is Extracting Components.

I'm always wary when somebody says a newer syntax is "hard to read". It's definitely possible to write code that is hard to read. But how can you say it's hard to read when you've spent years training your brain to parse some other syntax. Readibility is subjective with things like this.

For example, I found the example line in your article pretty easy to read. The purpose of md:h-32 and lg:h-64 are actually more obvious to me than the media queries. But I do agree the long horizontal line harder to read. But you don't have to do it that way.

I like your analogy of using single letter variables. But I don't think it's the same thing. These are just short forms of CSS properties. They are clear and documented.

I'm not sold on Tailwind myself. But if your conclusion is that it "provides no value", I don't think you argued it that well.

Thread Thread
brianboyko profile image
Brian Boyko Author

I don't know why you keep saying this is not how Tailwind is intended to be used. The page you linked to is titled "Utility First". I infer that to mean the expectation is you start with utilities, and move to something else if you need it.

Eh... If that is your interpretation of Utility First, then I can't fault it.

It wasn't mine, for a number of reasons, but you may have caught me out on an assumption I didn't know I was making.

See, I thought that "Utility First" was referring to a coding philosophy, much like the philsophy of "Mobile First" -- you code for the mobile site first because the mobile site will always work on the full web-page, but not necessarily vice versa.

Mostly, though, the reason why I don't think your interpretation is correct (Start with utility classes, then move away from them) is because almost every example on Tailwind's site is about how you can convert from semantic classes and CSS/SCSS to Tailwind Utility classes. If anything, Tailwind seems to suggest that CSS is a pain point that needs to be resolved and that utility classes are the solution.

I agree that Tailwind might have use with rapid prototyping, but there's no real instruction on how to move from rapid prototyping to final product - You write Tailwind, you distribute Tailwind.

I'm always wary when somebody says a newer syntax is "hard to read". It's definitely possible to write code that is hard to read. But how can you say it's hard to read when you've spent years training your brain to parse some other syntax. Readibility is subjective with things like this.

I remember a similar argument from the author of Clojure about how Clojure (and other Lisp-like languages) were "hard to read." He said: "I don't know how to read German, that doesn't mean that things written in German are hard to read."

But we can admit to ourselves that it is harder to learn certain languages than others, especially for an English speaker. And we can ask questions: Does this have a similar grammatical syntax? Does the language belong to the same family, does it have cognates and loan-words? Does it use the same sounds and tones? Is the alphabet the same?

In the case of programming languages, we can ask similar questions:

  • Does the syntax provide valuable information about what it does? ('height' vs. 'h-', for ex.)
  • Is the syntax internally consistant (Not actually a problem with Tailwind, though PHP suffers from this.)
  • Does it introduce concepts not familiar to other languages? (C's lack of memory safety, Rust's 'ownership', Lisp's Polish Notation, and if you're coming from a dynamically typed language like JS/Python, static typing of TS/C#/Java/C++?)
  • Is it relatively clear to follow the structure of a program written in this language? (CSS is horribly bad at this, as priority order rules can get complex, latter styles overwrite former ones, and of course, there's the !important flag.)

In this case, my criticism of Tailwind being "hard to read" deals primarily on the fact that the syntax is not expressive, and indeeds, chooses terseness over expressiveness. Back in the days of limited memory, sometimes a terse command was better than a long one, we still use "cd" for change-directory and "ls" for "list" in most Unix shells, but no such memory problems were at play here.

It's also hard to read because it's embedded inside HTML, listed horizontally, rather than vertically. Now I'm not saying that it would be as hard to read as if we did styles in PDoublePrime but compared to the default of regular CSS, it makes it hard to read. Additionally, since you're no longer adding your own semantic class names to your HTML, it can be hard to tell by looking at the source exactly what element in the HTML code you're actually looking at when you debug it.