Having a prebuilt consistent design system that you don’t have to build out for each project, arguing over defaults among the team is a lifesaver.

But you don't need Tailwind for that. A "designsystem.css" file with custom properties would do the trick. Without any added third party tech.

Why should anyone care about adding third party tech?

This argument boils down to: “But you don’t need Tailwind for that. You can do more work for a (almost certainly) worse result with a designsystem.css!” Sure you can! Why?

(Almost certainly) worse? Haha. Why would it be?

If you really want to, you can even use Tailwind's naming for you language file. The thing is, you add complexity to do a job that could be done in the same way without adding complexity and dependencies.

Shouldn't we try to justify added complexity through added value?

> why would it be?

Because most frontend engineers cannot make something as visually appealing as Tailwind’s defaults and most designers cannot make frontend abstractions as ergonomic as Tailwind’s.

Now it seems like you’re suggesting just reimplementing Tailwind? Or yes you can have one of your FE engineers and one designer try to dream up your own Tailwind but again: why? Now you’re consuming two people for something that can be achieved by literally zero people and “yarn add tailwind.”

It is not at all my objective to “reduce complexity” that sits behind good abstractions. My goal is to ship product and to put as much complexity as possible behind good abstractions and ideally out of my team’s maintenance burden and Tailwind helps achieve all of those.

Sure, if Tailwind provided literally zero value I would say you shouldn’t add it to the codebase. But it provides a huge amount of time-value (the best kind!) in my experience, so “there’s a package from the internet” is hardly a consideration whatsoever.

If the Tailind defaults are used in a design language file, wouldn't it be simpler? If it's only a problem of "aesthetics", 20 minutes is enough to use Tailwind's defaults in pure CSS. No need for calling a designer here either.

Side benefits include that there is then no need to update any dependencies or library, no need to run a JIT server, no need for a new syntax, no need to wait for implementation of new CSS features, better performance possibilities, etc.

Just checking that I understand your suggestion: it’s that you copy/paste Tailwind into a file called “designsystem.css” and then say that you are not using Tailwind?

Or are you saying take their design system and use your own syntax for it (so it’s less complete than TW, less well-documented, and less transferable to/from the vast resources of the internet centered around TW)?

I'm talking about the design aesthetics included in Tailwind as default. Keep the values and the names if you want. Like this, for example:

"blue-500" becomes --blue-500. That's it.

This is a far cry from using Tailwind as a whole while keeping the good-looking aesthetics.

Sure now do the same for: whitespace (margins and padding), border radiuses, shadows, opacities, font sizes, font weights, and continue playing whack-a-mole as you run into new cases.

Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set of classes that took you zero hours of initial setup and will cost you zero hours of maintenance outside of your own use/application until the end of time. And it has a name so when a new engineer joins your team, you can say "we use Tailwind, go to tailwindcss.com" and they are fully read into your setup in about 15 seconds.

mt-100 vs. margin-top: var(--100);

And the IDE will help you autocomplete it all. The same is true for all the other properties you enumerated. If it's a Tailwind design token, it can be a pure CSS design token. No "whack-a-mole" needed here.

Still, you're right about having documentation. And there has been a loooot of these kinds of doc (BEM, SMACSS, ITCSS, etc.) in the last 15 years. Nonetheless, a more modern-oriented one is indeed needed. And that's why I'm working on something like this.

As for the "15 seconds", I mean, really? If so, I beg to disagree. There is a lot to take in. And that is why numerous colleagues still have to open the Tailwind docs to know how to write a class that's not 1:1 CSS.

And lucky you if you haven't had any update and dependency issues in the medium to long term. But I know we had.

> Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set "of CSS features".

The sentence above is every bit as true as yours. Add a beautiful design language and you are in business.

> "blue-500" becomes --blue-500. That's it.

Of course it's not "it".

Now in every class that needs it, you also need to add

  {
    ... other styles...
    background-color: var(--blue-500);
  }

And then you need to apply that class

How is that different than writing "bg-color-blue-500" in every component that needs it?

As for the class, it's the name of the component, the same name you give to the component file. Does it really add that much work?

Correct me if I'm wrong but as I see it, that's literally a couple of seconds of "work".

> 20 minutes is enough to use Tailwind's defaults in pure CSS

not 20 minutes, more. Plus all the boilerplate around @media rules

> no need to wait for implementation of new CSS features

What CSS features are you waiting for with Tailwind?

> better performance possibilities

It's very hard to beat Tailwind's performance since it's a fixed set of css classes (and a very small set in production, since it only includes classes you actually use".

Boilerplate? What do you mean?

Any IDE can autocomplete 90% of any media query. And, on a sidenote, I was only talking about using Tailwind's default aesthetics in pure CSS, here. That's what the 20 minutes refers to. And I think it was a conservative estimate.

As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there. It took years for Tailwind to support "group hovers". And I can give even more examples if you're still not convinced. Or you can have a look at the changelog.

As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded? And that's not even considering the weight difference between the "tailwinded" HTML and the one needed to support pure CSS. These things matter if performance is a goal (as it should be).

If I'm missing something, go ahead and tell me, I'll be reading with great interest!

Boilerplate? What do you mean?

    :root {
      --gap-default: 2rem;
      --gap-large: 4rem;
    
      ... 30-40 more vars ...
    }
    
    .component1 {
      margin: var(--gap-default);
      padding: 0 var(--gap-large);
      ... more styles like this ...
    }
    
    @media (min-width: 640px) {
      .component1 {
        padding: 0 var(--gap-default);
      }
    }
    
    @media (min-width: 768px) {
      .component1 {
        ... other overrides
      }
    }
    
    /* potentially repeat for other breakpoints ...*/
    
    /* repeat for all components */
    
    /* repeat for some internals of some components */

There's a also a good (if contrived) example directly at Tailwind: https://tailwindcss.com/docs/utility-first

> As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there.

No one stops you from using whatever CSS you need alongside with Tailwind. I do that for the excellent layout breakout I found here: https://ryanmulligan.dev/blog/layout-breakouts/

Can't see how this makes Tailwind "ant-CSS".

> As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded?

Tradeoffs.

Most existing solutions can't even detect duplicated CSS. So if your existing component already has `width: var(--some-var)`, and you load a different component with the same style... You will still load that style hidden in a different (often auto-generated unique) class name.

Meanwhile with Tailwind has a fixed number of classes that apply to all components equally.

So, if you have a complex app with multiple component variations, of course you'll need to split your CSS and only load relevant CSS for displayed components. Because your CSS grows with the amount of variations, and each of those variations becomes its own unique class.

For Tailwind though that growth slows almost immediately because... it's just a fixed set of classes.

Thanks for the great reply.

Here are my thoughts:

In your code example, all that is in :root should be used from project to project. As it is Tailwind. Only values should change. Again, same as Tailwind. So I don't really see a problem.

For .component1, you would do the same in Tailwind albeit with fewer characters but as I said, your IDE should pick up the slack here.

mb<tab> --gap<tab> and it is done.

As for your duplicate width problem, it can be solved easily with a linter that prevents styling across files. I'll give you an example if you're interested. At the same time, you would be repeating "width" across components in Tailwind too.

So the duplication still exists, if I understand correctly. Same with the growth of CSS... In Tailwind you grow the HTML instead. Fixed clases or not. I don't see how it is better but, again, maybe I'm missing something.

As for the media queries, same as above: your IDE should pick up the slack.

BUT!

The thing is that by writing modern CSS, you would not need most of these media queries! Do you know "clamp()[1]"? It's magical

And unfortunately not supported in Tailwind at the moment

.component1 { clamp(var(--gap-default), 1vw, var(--gap-large)) }

the above will do what you want without media queries! clamp() solves a loooot of these use cases. Honestly I don't write much media queries anymore and yes, that's great.

And if I may, I think Tailwind here prevents you from thinking about better and simpler solutions like this one. If it ain't included in what you're using, it's normal to not think about it. But really, this is a game changer. And it's been available for certainly three years. That's a lot.

And in the end, I'd say using real CSS with Tailwind kind of defeats the purpose. You end up with different styling methods for different components. I don't think that's good. More like a "hack".

But really, your example above is right on point: by excluding new approaches, Tailwind disincentivize you from using them when they would solve many of your problems elegantly and simply.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/clamp

edit: the Tailwind example provided is bad CSS. As were the ones given in the first fundamental post by Mr Wathan. These are strawmen. If you're interested, I'll give you an example of good CSS producing the same output.

What are you building where CSS and the "weight" of HTML is a real performance consideration?

Well, I'm building websites and apps.

And, as I'm sure you know, milliseconds are important in our craft. You can easily shave or add hundreds of milliseconds with HTML or CSS.

And to be honest, I find your general line of inquiry here to be quite agressive and dismissive. I think, respectfully, a little more good faith could further our understanding of each other.

The question about what you're building such that you care about perf characteristics of CSS is an effort to understand you, I am sorry I failed to come across that way.

Outside of consumer apps I am struggling to imagine a case where the HTML/CSS perf delta would be more important to capture than faster development time. I suppose part of why that doesn't seem like a good faith question is because you don't believe Tailwind dev time to be faster, so the tradeoff that I'm trying to evaluate is totally inane.

First, sorry for the response delay. I don't know why I didn't see your answer.

As for the case in point, in fact, I think CSS can be as fast if not faster. But that's totally for me to prove. Hehe.

That's why I'm working on a set of simple rules for efficient styling with CSS. A website with documentation, examples and tools is in the works. If you're interested, I can give you a heads up when it's online.

Feedback from Tailwind users is important and would absolutely be welcomed!

PS: thank you for the explanation.

I tried to do that once. I decided to skip Tailwind and "just" bring in a few CSS variable that cover what I use.

By the 30th variable I stopped. The fact that I had to write significantly more boilerplate in CSS classes on top of that, helped me stop, too

If you know CSS why are you using Tailwind which is esoteric CSS but worse? Just use CSS.

Because it’s way, way faster to build with; yields more easily composable, less brittle components; and has a very solid (and rather unopinionated) design system baked in.

So glad to read comments like this. I cannot believe my eyes that most devs these days just don't get it and litter their projects with layer upon layer upon layer of unnecessary complexity.

I thought a person had to be rational to become a developer but oh my, how wrong I was.

Everyone is a developer.

This is the paradox of popularity. The theory goes that if you have a large pool of X to select from, then you can select the best of the best, and the quality of your selection will be amazing.

But it's exactly the opposite. Small groups are self-selecting for quality and big groups are self-selecting for quantity. O_O

English, the universal international language. The one we're speaking here, right now. The worst translators in the world are English translators. Everyone feels qualified to speak it and translate it. Finding a good English translator is like looking for a needle in a haystack.

The more "easy languages" and "frameworks" we have, the more "programmers" we also have, and 99.999% of them have the faintest clue what they're doing, but they just keep hitting their keyboard with a hammer, and it compiles and produces interesting results, so they keep doing it.

This is also why social networks have an amazing set of interactions when they're new, and in an old social network you have hundreds of millions of users, but no one writes anything interesting, anyone barely reads, and it's full of scams, bots, clickbait and garbage.

There's safety in numbers, the saying goes. Not at all. If something is universally popular, and you choose to enter it, get ready for a shitstorm.

P.S.: Tailwind is garbage.

Are there any resources like tailwindui or shadcn ui that are built on plain CSS, that are actually consistent and high quality?

Care to show one simple example where tailwind's amazing docs cover something MDN or css tricks and others do not?

MDN's docs are amazing, but they are about everything. "CSS tricks" is not documentation (except some very helpful articles).

Meanwhile in Tailwind everything is grouped together, can be searched quickly and acts both as quick docs [1] and as quick reference [2].

I personally have become proficient with flexbox by playing with Tailwind classes.

[1] E.g. layouts https://tailwindcss.com/docs/display

[2] E.g. all the justify-content values https://tailwindcss.com/docs/justify-content