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.

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

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.

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

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

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

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.

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?

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

  .InnerWrapper {
    padding: 3px 7px;
    margin-left: -9px;
  }

Good luck catching everything, including this class and its usages, without manually reviewing everything that is used like a button, inspecting the HTML, then going over the classes, one by one, without breaking some unintended side effect.

What makes you think that? I wouldn't use a wrapper element from a different component in another component. At some point you just have to use common sense.

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

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.

  const StyledButton = styled.button`
    background-color: ${props => props.theme.primaryColor};
  `