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.
> 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.
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.
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.
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.
Does Ruby have an ORM/HTTP request handler/URL router in the standard library?
I am not sure I follow the analogy. If all you are taking from tailwind is the utility classes, fine. This is the part that provides value. But tailwind is not just that, is it?
Rails is a fully formed opinion on how you should write a web app in Ruby and all the various technical components you need to fully realize that opinion.
Tailwind is a fully formed opinion on how to use CSS (utility classes etc.) and all the various technical components you need to fully realize that opinion.
Thinking of Tailwind as just a bunch of regular CSS utility components is misunderstanding the scope of the project. That alone has a lot of tradeoffs and compromises - the file size is absurd and you can't bundle things into components, you also can't have arbitrary values in the utility classes. It wouldn't be a complete opinion on 'the best way to use utility classes', or however you want to frame Tailwind.
