[PUSH_AX]

I love tailwind. I strongly feel that most modern CSS solutions are massively overthought. In engineering we have bigger problems to solve than a key/value list that makes a div blue.

Tailwind removes the thinking around CSS, naming, preprocessors etc etc, it just lets me write good CSS and focus on components and other engineering problems.

I seem to be one of the few people who can read CSS properties horizontally as well as vertically, so I'm all good on most peoples major complaint.

[dbbk]

Why not Styled Components? I've been using them for years now and I'm extremely productive.

Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components.

[onion2k]

Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components.

Is "horizontal reading" worse than reading two files?

What if the other file is actually 30 files compiled with SASS?

What if they're 30 files, compiled with SASS, and written by a bunch of devs who don't know CSS well, didn't use BEM or anything to name things well, and didn't organise them at all?

Tailwind isn't better than great CSS, but it's significantly better than bad CSS.

[dbbk]

> Is "horizontal reading" worse than reading two files?

I see this complaint a lot but I don't really get it. You can have a styled component in the same file or a separate file. In VSCode, you just command click on the component and you go straight to the style definition. Not an issue.

> What if the other file is actually 30 files compiled with SASS?

I only work in Styled Components-exclusive codebases so can't comment

> What if they're 30 files, compiled with SASS, and written by a bunch of devs who don't know CSS well, didn't use BEM or anything to name things well, and didn't organise them at all?

You got bigger problems

[onion2k]

You got bigger problems

Yes, you have. And this is really, really common in large scale web apps, especially where they've been mostly written by people who are 'backend' or 'full stack' developers.

Tailwind didn't just spring forth as a tool to screw with web developers. It was developed as a solution to a problem. That problem being bad, unmanaged CSS at scale. If you don't have that problem obviously Tailwind isn't going to look useful to you.

[lawn]

> Is "horizontal reading" worse than reading two files?

Yes, very. I'm amazed that this is even in question.

[9dev]

If horizontal reading bothers you so much it resembles a hellish nightmare (Dante would like to have a word with you), nobody stops you from going like this:

  <button class="
    flex
    bg-blue-400
    p-4
  ">Submit</button>

And you actually can target other components. There are lots of sibling selectors, including named groups:

  <label class="group/field">
    <input type="text" />
    <span class="order-1 text-black group-focus-within/field:text-blue-500">Name</span>
  </label>

[ricardobeat]

> removes the thinking around CSS, naming, preprocessors etc

[9dev]

It's a fairly limited set of rules that are mostly consistent, extensively documented, and easy to remember. But yeah, a little bit of effort is required when dealing with a styling language with over 300 properties.

Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon. At first it's a button, then there's buttons that should look like links, and then clickable icons. They share some properties, but not others, and before you know it, you've invented an ad-hoc description language in CSS classes that nobody except you can understand right away. With Tailwind, you may have sequences of tokens that seem confusing at first, but at least it's the same -- few -- sequences in every single Tailwind project under the sun.

No side effects, no blurry concerns, no more specificity issues. If you don't appreciate that, you haven't seen large enough projects yet.

[dbbk]

> Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon

I can honestly say I've never spent more than 5 seconds thinking about what to name a styled component, do you really get decision paralysis with this?

[9dev]

This isn't about decision paralysis, but picking good names that other people will understand. But they won't, not all of them at least. No matter how great you're at naming things, you are going to do it differently than other people do. That doesn't matter on your personal home page, but it breaks down with a larger team. Inevitably, naming principles will drift apart, and after a few years, you'll have a mess. Don't believe me? Read the myriad of blog posts of development teams coming up with new CSS frameworks or migrating from one to another, to combat this.

Tailwind removes the naming ambiguity here, by moving away from naming things to describing the styles in a composable way. Drop your new hire in the code base, give them access to the Tailwind docs, and they'll be productive immediately (even more so if they previously spent half an hour with it).

[s0laster]

Damn, that's an awesome trick, thanks for sharing!

[PUSH_AX]

My personal opinion is that styled components creates an unnecessary and fuzzy extra abstraction on top of components.

[dbbk]

Not really? It's just an element with some attached styles.

styled.div`color:red` is a red-colored div. Hardly fuzzy.

[onion2k]

The equivalent styled component of the default Tailwind button of "bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" is "styled.div`background-color:#8888ff;color:white;font-weight:bold;padding-y:2px;padding-x:4px;border-radius:4px;&hover{background-color:#aaaaff}`".

Obviously you wouldn't actually write it like that because it's inline in your code so you can format it better, but the Tailwind version is less verbose and easier to read if you did.

[dbbk]

"Less verbose" I guess by a few characters... at the expense that you're not writing real CSS rules. So you're having to translate every rule into whatever Tailwind's syntax is for the same thing.

[9dev]

It's not the same thing, though. Tailwind applies rules from your design system, not plain CSS values. Assuming you're updating your corporate design to use border-radius 2 vs 4 everywhere, with Tailwind it's a matter of reconfiguring your design system configuration; with styled components (and other approaches) you're going on a string hunt.

[ellinoora]

My biggest issue with Tailwind is point #5 on the article: Tailwind encourages div/span-tag soup. Together with the class name soup my HTML becomes unreadable.

[batperson]

A big issue that these articles never mention is that using browser dev tools to debug CSS becomes a huge pain with tailwind. It also makes it harder for community to create custom themes/user scripts for your website/app since targeting specific elements becomes incredibly hard when no class names exist.

[angra_mainyu]

This so much.

Not to mention, it basically puts a dsl on top of CSS.

CSS by itself is great, and with all the modern changes you hardly need to use preprocessors like SCSS (there's still some advantages but far fewer than say, 5 years ago).

I don't understand the people in the thread that hate writing CSS...

[beejiu]

> HTML becomes unreadable

To be honest, I don't find that a problem. Most frontend development is done in a higher-order abstraction like React. For the most part, I don't read HTML and I don't write HTML. If you use the right level of composition, "div soup" should never really be a problem.

[cryptonym]

Not great for accessibility, not great for performance.

[ellinoora]

> I don't read HTML

For a reason

[troupo]

How does Tailwind encourage div/span tag soup compared to anything else? You literally cannot do anything on the web without a div/tag soup

[hmcq6]

It doesn't the author is just bad at semantic HTML. That first example should be an `<article>` and the 5th example doesn't actually show div/span soup.

[timeon]

> most modern CSS solutions are massively overthought

Example is Tailwind. Which in the end is same as inline CSS.

[PUSH_AX]

This is false and people need to stop parroting it..

Inline styles have high specificity and are often the culprit of specificity clashes.

Inline styles don't follow a design/theme, tailwind has sensible defaults for spacing/colours and consistency etc.

Inline styles are even more verbose than a tailwind class list.

Tailwind has responsive classes out of the box.

Inline styles don't really support pseudo classes....

[PrimeMcFly]

> read CSS properties horizontally as well as vertically,

What do you mean by this?

[tipiirai]

Curious: which modern CSS solutions are you referring to?

[PUSH_AX]

For example, styled components, stylex etc.

[tipiirai]

Gotcha. Are all modern solutions CSS-in-JS based?

[Franzeus]

I love tailwind too. The article did not convince me as there was also no real solution / alternative proposed.

I have written custom css since the year 2000 and using tailwind just makes me much faster (is like setting flags) and simply by reading it, I understand how an element looks like. No matter if my past-self wrote it or another engineer.

It can pollute the HTML (although @apply helps a lot to define your reusable .title, .card, .btn, .btn-lg, .btn-primary etc), but at least it is written in HTML and not in JS, which is even harder to transfer to other eco-systems.

Also extending styles (tailwind config) is amazing if you want to reuse your styles in other projects.