4 Reasons for Tailwindcss
I’m neither a CSS guru nor a Tailwind expert. I’m someone who has changed their mind on a principle and never looked back.
Responsive Design in the browser
This point is most relevant to developers who do design. The best development workflow is to preview your site on localhost, make adjustments in the browser until you are happy with it, and then copy and paste your changes straight into your codebase. Let’s call this the design in browser workflow.
If you want this workflow, you rule out using React’s inline styling (which make you use object syntax). But let’s say you do use some form of “Write Real CSS”-solution like styled-components or vuejs scoped styles, where design-in-browser is possible. What else does Tailwind offer you?
You can pull directly from preset values while prototyping in browser. You can do responsive and pseudo-class design while in browser too for example to apply styles at different breakpoints, or on hover or focus states, you can just prefix inline.
Purge of unused styles
One of my favorite features of Tailwind is the Purge. I have seen CSS files longer than 10.000 lines of code with predefined templates. With utilities-frameworks like Tailwind you have a large bunch of utility classes.
But! Tailwind allows you to purge all of the unused classes. So it is really easy to reduce your css from Megabytes to Kilobytes.
Inline styles reduce naming
Finding names for CSS-classes is a hard problem. We waste a lot of time searching over naming classes. Although with styled-components, you often write a bunch of components you have to name. Have you ever thought about how many hours you spent on it?
With utility CSS we significantly reduce the total number of names in our codebase, and perhaps more importantly, the number of names we have to independently invent and remember. This feels minor until you’ve worked on a codebase where it isn’t. What price are you willing to pay to eliminate one of the known known hard problems? I’m not kidding, this is a conversation worth having. Names don’t matter to machines but they matter to humans.
The tradeoff is you have to learn the names from the utility CSS framework. The difference is that traditional CSS naming is bespoke per project, where as you learn Tailwind once and can use them in every project. Yes, you could try to roll your own utilities, but Tailwind’s naming is probably more thoughtfully designed than whatever you come up with.
Utility-First, not Utility-Only
When you take a look on the benefits above, you can still use other solutions for the benefits you want. For example, nothing is that powerful like CSS-in-JS, where you can dynamically change media query values and entire rulesets based on JavaScript. However, the usecases in which you need to do this are limited, and the costs dominate when you just use it for static styling.
Going utility-first respects the principles of least power. Non-CSS-in-JS solutions are often easier to debug. No more getting deep into Github issues and diving through node_modules. When bad things happen with Tailwind, i know that i’m either generating the classname i expected, or i am not. There are much fewer points of variance. And i think, you would like to use the easier-to-debug solution most of the time if you can.
Conclusion
Far from everything that has been said so far, I think choosing Tailwindcss is a matter of personal preference and project needs rather than being the objective right answer. There is a wide range of good styling solutions. Premade component libs are too restrictive, plain css is too permissive, CSS in JS is too heavy, and inline CSS is too underpowered.
A solid in-between for designers that want freedom and devs want structure. — Ben Holmes
Tailwind is for people who desire a styling solutions that is “not too cold, and not too hot”.
