"Build times reduced", "no more @tailwind directives", "No more js configuration", "Designed for the modern web".
To me, this screams "CSS now can do everything we used to do ourselves, but let's keep pretending that we are still needed somehow"
To me, this screams "CSS now can do everything we used to do ourselves, but let's keep pretending that we are still needed somehow"
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?
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.
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.
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.
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.
maybe you got it wrong? CSS already have its place and work great as .css files
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?
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.
Tailwind was never about filling gaps in CSS.
If modern CSS makes styling as easy as Tailwind does, I'd love to read about it.
Tailwind solves css confusion by presenting a “paved road” for many tasks. Want to do “thing”? Just look up “thing” in the tailwind docs, add “thing-2” to your class, done in 2 minutes. Rather than look up “thing” on google, skim several articles, then write 4-10 lines of CSS, done in 30 minutes.
As CSS has gotten more complexity from new capabilities, solving various tasks with it feels more and more like a research project. Like centering a div vertically and horizontally - there’s now 3-4 generations of solutions for this task:
1. Hacky stuff with position: absolute or floats
2. Flexbox approach. Hope you remember the 6 different attributes you need to set! Oh, there’s a new shorthand for flex now? Cool! More stuff to learn.
3. Grid approach. There are a bunch of different ways to structure a grid centering approach. Hope you remember how grid templates work!
With tailwind, just add 2 classes, done.
But you can do that with a library of SASS mixins as well.
Going through some of the answers I'm noticing that another "issue" I have with the tailwind approach is that it works by providing a post-processor when in reality most people just need a simple preprocessor and macro system.
I like SASS (I wrote a lisp in SASS in 2011 lol) and that’s actually how I think about Tailwind utilities - it’s just using SASS mixins directly in your HTML. I would rather use Tailwind because it will take 1/3 the levels of abstraction, 1/4 the keystrokes and 1/2 the files to do the same job to:
1. Pick a class name (myclass) if people are using BEM or something this requires some algebraic thinking.
2. Write the class in file.scss to define the class and include mixins A, B, C
3. Add class=myclass in my html.
Vs tailwind:
1. Add class=“A B C” to my html.
I don’t really get pre processor vs post processor, it’s a build step to run at some point before I deploy with either tool that will produce some css files. ¯\_(ツ)_/¯
That's a separate argument.
I hear mostly two justifications for tailwind:
1. It is (or used to be) hard to do things in CSS like variables, calculated properties, themes, scoped rules / namespacing. (Pre/Post) Processors are going to be required anyway, so we might as well use Tailwind
2. It gives frontend developers and designers a common language (the utility classes) which makes it easier to establish workflows.
My argument for (1) is that CSS already supports a lot of things that used to require processors, and (2) could be achieved with a simple "library" that could just be imported directly.
My take is that it removes needless indirection in any codebase that already has “components” - react/vue/solid/etc, template partials, functions that return html strings, whatever. See comment here: https://news.ycombinator.com/item?id=42804831
For that reason, plus it’s concision, I find it more productive use of time compared to css-in-separate-file.
If you don’t have components for separating semantics from presentation, then tailwind is less a good fit.
Not quite the same. If it's only a preprocessor, the tool is only dependent on your styling code. A post-processor needs the whole application.
It's a lot easier to add or remove a pre-processor from your development process, and for those that want to consume your styles it is a lot nicer when you don't have to adopt their tooling as well. E.g, I can create a "utility class library" in SASS, generate the CSS and let people just import that directly into their web pages. Is that possible to do with tailwind?
False dichotomy. You are not stuck between tailwind and "Vanilla CSS", and one can solve the issue you are presenting with any reasonable set of SASS mixins.
> If not inline, what should I name the class?
Also solvable with good old SASS.
Tailwind is styling utility classes and design tokens in one. There are premade design tokens you can use the CSS styling though.
Also inline css doesn't allow media queries, pseudo classes, etc., which is a big deal.
Much of it does, but not all of it.
The original question wasn't whether Tailwind can do something CSS can't, but whether it was a 1:1 mapping.
Can regular CSS do media queries all within the element's style attribute?
I believe Tailwind also utilizes JS to get some convenience features to work.
I want to say that tailwind also can't do inline media queries, but that's getting really nitpicky and pedantic. You can at least add a class inline that Tailwind creates a media query for in CSS, that is really handy.
I understand you're not a fan of Tailwind, so perhaps say what you dont like about Tailwind instead of creating a strawman and attacking it.
Also, shame on you for poo-pooing on someone else's open source project and people find useful.
> poo-pooing on someone else's open source project
This is not some young kid doing free software out of kindness. This is a company making millions of dollars in revenue in a closed source product (tailwind UI), which is built on a foundation (tailwindCSS) that is becoming less and less needed.
As someone who's done it both ways with web sites, that separation sucked. Having to figure out which style in my CSS file was messing things up was always a pain. And Tailwind tends to be "local" by default, limiting the damage done to other elements when I style an element.
In my larger experience (not just with web sites), whether separating content and presentation is a good idea varies widely from use case to use case.