[fc373745]

I completely disagree.

To fix the css + jsx in one file, just write your styled components at the bottom of your component.

If you ever seen a react component completely riddled with Tailwind, you'll realize how messy and uncoordinated it looks.

Even I would consider switching between two files just to avoid that style of css.

Furthermore the necessity to utilize horizontal scroll because adding 10+ more rules will inevitably break your prettier printWidth rule is, by far, the most annoying aspect of Tailwind.

    absolute inset-0 bg-gradient-to-r from-cyan-400 to-sky-500 shadow-lg transform -skew-y-6 sm:skew-y-0 sm:-rotate-6 sm:rounded-3xl

    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    linear-gradient(45deg, #fff, #000);
    box-shadow: 1px 1px 1px 0 rgb(0 0 0 / 0.05);
    transform: skewY(60deg);
    border-radius: 4px;
    transform: rotate(60deg);

Consider these two snippets, after time of not looking at your css code, do you think 10+ rules on one line is maintainable?

Not even close, ask yourself to change a css property - you would have to iteratively go from left to right until you find it, whereas looking from top down you can immediately catch the css rule you want to find.

Succinct doesn't mean maintainable, and sometimes verbosity does.

Tailwindcss isn't even close to being the future.

[majkinetor]

You seem to miss the bigger point - Tailwind constraint your css use so that you don't imagine stuff in ad-hoc manner.

And you can split, and sort classes with editor plugins which makes it almost equally good as your example.

[shroompasta]

i think you missed his point to be honest.

Regardless of where place your tailwindcss or where you split / sort classes, reading iteratively from left to right, especially if the css rules are numerous, is not legible.

just looking at the two examples above, and already I can tell how much it would be easier to maintain verbose css.

[majkinetor]

So u cant manage the little bigger list of words? And you can manage way complex software behavior at the same time? Particularly if it lets you manage small subset of CSS ?

[jonfleck]

I wrote a “function” for this exact reason. It’ll display the classes in a much easier to read way. It also can type check to ensure that all classes are valid. I say function in quotes because it’s actually a babel macro that’s get compiled down so there’s no runtime cost! https://github.com/fleck/class-types.macro#better-prettier-f...

[pier25]

That's the biggest problem with TW IMO.

It's much more difficult to scan a list of classes in a single line. With CSS I can quickly scan the declarations from top to bottom until I find the thing I want.

Complex nested declarations are also super easy to scan when using SCSS. When you start adding pseudoclasses with TW it becomes a shit show.

And it really makes the markup an absolute mess for anything other than trivial examples.

People complain about not knowing where the styles are, which was a valid concern when doing old school CSS (everything in a couple of files) but I haven't had that issue since I started using SCSS in almost a decade.

When doing front end with components I store the SCSS for the component in the same directory of the component file. Eg: MyComponent.svelte and MyComponent.scss. Super easy and clear. I've also written a small VSCode extension that allows me switch between the component and its SCSS file with a shortcut. I don't even have to open the SCSS file or look for it. I configure Webpack or whatever I'm using to automatically include the .scss files in the component folders. I have all the convenience and control I want without relying on something as convoluted as TW.

[jozzy-james]

explain to me how this compiles

  .class1 {
    .class2 {
      &:hover {
        font-family: value;
      }

     body.some-thing & {
       color: woooooo;
     }
    }
  }

[unleashit]

I don't think the example compares. In languages like JS, double, triple or even further nested ternaries are possible. But terser isn't always better because human readability is important. I can easily understood your SASS example because I know SASS, but I'd never write it like that. If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.

The problem with Tailwind is there's nothing you can do to avoid the much more difficult to scan and understand syntax described above. I personally don't understand why people are drinking this koolaide. I really think this is a fad a lot of people are going to come to regret when they go back to maintain older projects based on it.

[jozzy-james]

> If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.

a) maybe you don't really know how far up the chain that tag gets called from.

b) it creates new selectors for class1 and class1.class2, as well as class1.class2's hover

c) creates a hyper specificity

now, I'm not advocating this usage of SASS - but it can be a handy hatchet when you need to support multiple themes with minimal changes/effort, much to the chagrin of specificity and maintainability

[unleashit]

The point I was trying to make was just because Tailwind doesn't happen to be expressive enough to get you into that particular kind of mess isn't a reason to use it. True, its fair to say you can write bad CSS or SASS, but that's the same for all programming languages. If your main goal is something foot gun free and safe for the inexperienced, might as well go all the way and recommend low/no code or even Squarespace.

I think the reason a lot of ppl think they need tailwind, is because a) they aren't familiar enough with more current CSS techniques like CSS modules and linting which can limit stuff like nested descendant selectors and/or b) they're tricked into thinking they won't have to learn as much about CSS (a dangerous fallacy unless you're sticking to the most basic of prototypes!).

[pier25]

> I really think this is a fad a lot of people are going to come to regret when they go back to maintain older projects based on it.

Yeah 100%

But if you look at the State of CSS survey, TW is still relatively not as popular as Twitter or HN would make you believe.

https://2021.stateofcss.com/en-US/technologies

[pier25]

I guess the point you're making is that TW prevents you from making certain errors.

Which is technically true but irrelevant. TW doesn't prevent you from understanding fundamental CSS concepts such as the box model, cascading, etc. Anyone with even basic CSS knowledge would not write this nonsensical and malicious example you just used.

[aidos]

You can do both of those things with Tailwind. Put the css only components at the bottom and use them in your main component if you want. Break the classes over multiple lines if you want.

The difference between your 2 examples is that TW allowed you to handle media queries seamlessly but you couldn't do that in your styles example.

[teen]

Each styled-component also increases your css payload size linearly

[shroompasta]

i'm not sure what you mean by 'seamlessly'

but a media query in styled components would just be

    @media (max-width: 700px) {
        css here
    }

it's not that much harder.

Also, the lack of address of real problems of tailwindcss of OPs comment in terms of mantainability is something you consider.

reading iteratively from left to right especially if it has 10+ css rules, in terms of legibility, is not really all too great.

I would absolutely hate to adjust something in tailwindcss, after not seeing the codebase in a month's time.

Whereas regular css properties, i can easily find by eye.

[jmoreno94]

Your eye gets trained eventually. Also most of our components look something like this once class names start to get long.

  const inputWrapperClass = classNames(
    'flex flex-col gap-y-1',
    'group-focus:border-blue-500',
    isDisabled ? 'opacity-50' : null
  );

  return (
    <label className={inputWrapperClass}>
    {...}
    </label>
  )

In practice our "full-stack" developers are writing less and less CSS because they're just using the components that encapsulate all of this, our frontend developers get code completion for our design system tokens, and we haven't had to ship any new CSS classes in the last few months.

Our new hires are able to just use the design system tokens rather than going in and saying `padding: 5px` and `padding: 4px` because the designer didn't think it was a big deal. They just write `p-1` and that covers it.

All the components get tree-shaken and only ship the styles they need so bundle size gets reduced as well.

If I had my dream team of 10x frontend developers and a perfect design team who always follows the rules they create then yes I would use regular css with css variables, but I don't.

I am more than happy to sacrifice "separation of technologies" for a happier team, more consistent styling, and faster delivery times.

[aidos]

"Also, the lack of address of real problems of tailwindcss of OPs comment in terms of mantainability is something you consider."

Not sure what you mean by that. I've been doing this since we did layouts with tables and shims in the 90s. I've found TW pretty nice to maintain myself.

"It's not that much harder", but a) it's a simple example and b) now you're going to litter your code with a load of hard coded media widths?

Let's talk about something concrete. Let's take a really simple layout that changes border and margin responsively (this, for me, is seamless).

    <div className="m-8 lg:m-0">
      <div className="border-2 md:border-4">
        Content
      </div>
    </div>

How would you do that?

[andrei_says_]

I think it is already the present for people who don’t want to learn CSS.

I can go as far as using some of its standardized constants in my BEM codebases.

Snark aside, I believe the future of CSS is closer to ITCSS - working with the cascade to minimize the need to modify styles.

[jozzy-james]

your vanilla CSS doesn't actually work the same since the second transform overrides the first one