[rglullis]

Maybe you are making my point?

If tailwind was "just utility classes", fine. But what business would it be there if they just published a bunch of CSS files with their styles?

With modern CSS, what problem are they really solving now?

[kyleyeats]

As someone who made a competing product along these lines (that got no attention or traction): Tailwind gives CSS a "place" in the codebase. It benefits orgs, not necessarily apps. I didn't get it at first either. But it's very useful to the people to whom it's useful.

[rglullis]

> Tailwind gives CSS a "place" in the codebase. It benefits orgs, not necessarily apps.

That is a better argument. But couldn't we be able to achieve that by, e.g:

- Create one standard HTML document with a predefined structure and including all the web components needed by your product.

- Having all designers and frontend developers developing their CSS (or SCSS) against this single base document

This would be basically the CSS Zen Garden approach. It would still keep separation of content and styling and it would create a "place" for styling code.

[jitl]

This works for products with a very limited scope that are mostly content focused, with a very small design team so everyone can agree to use the very limited toolkit in standards.html. The approach of saying “All ui shall only use these 29 components, anything else is forbidden” is not going to fly in a company with 10s of designers and 100s of engineers.

We tried this style at Airbnb and it turns out forcing all UI changes - from either designers or engineers - to acquire a single exclusive lock on standards.html leads to a fuckton of contention and frustration, and soon people are just going to yolo their own thing totally ignoring the pristine blessed system because the system doesn’t work.

The art of design systems isn’t a single technical approach - it’s finding an optimal workflow so your design engineers can build a UI toolkit that your product teams will actually adopt and contribute to, within the constraints of your existing tech stack & organization.

[csomar]

There are more "modern" ways to do this for large organizations like Storybook. Tailwind is a proposition for a small business that has a very small budget, want to buy a ready-theme and then make slight modifications. In a sense, no, it doesn't make any sense beyond that to use it. And once you use a good React/web-components framework, you realize there isn't really much value there as you shouldn't be really changing the CSS from page to another.

The process for large orgs is tedious and too lengthy/expensive for the small ones. Imagine having to go through planning, visualization, creating the component (or adding props for customization, writing e2e tests, publishing it to storybook with docs, and then finally adding it to your page and get it pipelined in the merge CI/CD process. A small org with tailwind just open the page in question and add a class to the html element.

[joks]

As others have said, this is exactly what many large orgs do, but in a slightly higher-tech / more polished way with tools like Storybook, essentially creating their own CSS libraries and component libraries.

IMO a decent analogy is that Tailwind is to the above as something like Shopify is to being large enough to build your own ecommerce platform from scratch.

[rglullis]

What is stopping from someone just turning all those utility classes into a single CSS file and completely get rid of the post-processor stuff?

[meiraleal]

> I didn't get it at first either.

maybe you got it wrong? CSS already have its place and work great as .css files

[_heimdall]

In my experience, the main problem it solves is the fact that styling in react is still a pain in the butt.