As a once-strident critic of Tailwind for its many failings and incompatibilities with the state of the actually-modern "vanilla" web art, I am very pleased to see the huge strides they've made with v4. Being able to access the Tailwind theme through native CSS variables (they even have an example in the docs of a button component written in native CSS in an external stylesheet using native variables! Oh happy day!) is absolutely massive, and being able to use a CSS-only config is equally amazing. Finally, Tailwind feels more like it's a utility (ironic, since its claim to fame is utility classes!) which you can add to any project, rather than some bizarro "viral" framework that wants to eat sensible architectures and lives in its own JavaScript-y silo.
Perhaps all the criticism over the years actually had an effect. Or maybe they finally arrived at good conclusions on their own. Either way, I suspect many of the pro/anti-Tailwind arguments are no longer relevant, and that's a Very Good Thing. Now we can get down to business and ship product.
I'm still a critic in terms of actually using it, but what I find amazing about tailwind is how amenable it is to AI-generated workflows. It seriously works _so good_. Anything can be expressed, and systematically. There's something amazingly useful there.
> what I find amazing about tailwind is how amenable it is to AI-generated workflows
It's highly amenable to human workflows as well. Of course, humans are more disparate than AIs so it doesn't suit all humans - no tool can. But it sure does seem like a majority of humans web developers like it.
> I suspect many of the pro/anti-Tailwind arguments are no longer relevant
I feel there are two issues with Tailwind for me as a designer / design engineer.
* First, JavaScript/Tailwind engineers have hijacked the conversation on design. Instead of "utility-first," "dead code elimination," and "type-safe CSS" I focus more on desing systems. Whether to use Perfect Fifth or Perfect Fourth in typography for example.
* Second, Tailwind makes it impossible for me to participate in the actual craft. Design decisions get buried in React components with cryptic expressions like `flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]`. This might make sense for JavaScript engineers, but blocks/makes it hard for systematic design. Instead of expressing precise mathematical relationships through CSS, we're essentially writing inline styles with better ergonomics.
Tailwind has solved a lot of problems. And this is coming from someone who doesn't use it half the time.
Some thoughts about this topic, not necessarily in disagreement:
- Designers seldom think in the way you describe (explicit computer-readable rules, systems of design). A lot of designers are coming from crafts that are more implicit. It doesn't surprise me design business logic is not the topic of conversation.
- You need to update your tailwind classes to reflect your design business logic. Don't do "bg-gray", do "on-surface-emphasis" or whatever business logic. This is just a simple config change.
- You probably brought up modular scale as just one example, but modular type has become near myopic dogma of frontend engineers who haven't had any typesetting experience. A scale of 1.25 vs 1.5 is so in the weeds as to be useless. There are so many alternative ways to set type (e.g. take lessons from CJK typesetting) or innovate typography on the web (e.g. build your own leading-trim implementation!).
I'm a designer, so I absolutely think in terms of design systems where typography is just one part of the puzzle. There are, of course, many ways to set type — but the point was: no Tailwind engineer talks about typographic scales in the first place. Systematic thinking is absent, which is naturally built in CSS.
Tailwind itself is a design system. The authors actually put together a short book explaining their point of view on design systems (without referencing Tailwind) and I found it very difficult to argue with any of their points.
Then you look at Tailwind and realize it’s almost entirely that book packaged for others to use.
The Tailwind library names grades of colors and sizes for you, but the book is ultimately about iterating design so that you can create your own design system. From the perspective of the book, the Tailwind defaults are inadequate as a design system.
Not really the same, although I realize it can seem that way.
If you go low level enough everything technically fits that bill, it’s just a matter of how much work you have do to put the structure in place and what the burden is for other people to learn it.
It’s akin to raw Perl vs Ruby on Rails. You can do it that way, nothing is stopping you…but there are compelling reasons not to.
That's exactly the argument I'm making about Tailwind. Inadequate as a design system. You have these bundles of rules just a thin step above CSS and there's nothing obvious about how things should look.
I'm kind of surprised why this is even relevant to you. The designers I know work in Figma. The designer and the engineer collaborate to make sure the design isn't too hard to implement, but other than that the designer shouldn't care about whether developers are using Tailwind, StyleX, Sass, vanilla, or whatever.
I hardly expect a designer to take responsibility for something as transient and idiosyncratic as "oh, but this is hard in Tailwind."
Maybe Tailwind is useful for bigger projects, but I tend to prefer component based class instead. The biggest DX for CSS is using the web inspector and directly modifying the DOM, then copying the adjusted values to the text editor. For a much serious project, I go with the balsamiq -> figma route to create an actual design system.
How can anyone prefer this gobbledygook over a nice CSS class declaration with line-separated standard CSS properties ? How can one even maintain this ?
Maybe the modern generation of web developers have IQ 200 and 20/20 vision with eidetic memory and I should just put myself to pasture.
Because your not thinking of styles practically. You don't review style declarations, you review the rendered page/component. You see with your eyes that a component has the wrong border color, and AFTER THAT you go to your component code, find the border color declaration (if any), and update it/add it. Sometimes you'll even inspect the element in browser, and find the faulty class directly, making it even easier to target in code.
The Tailwind classes are "unreadable crap", that's true, but it's not a problem because you don't "read" it, no one does. You roughly parse it and edit it.
Exactly, it's not like a novel where you are trying to read the entire thing. And it's an advantage because it is easier to parse. If I'm trying to change the color on that element, I have a very good idea what controls that. As opposed to something like "card_wrapper card_wrapper--striped". That certainly looks better, but if I'm just there to change the grid, now it's a more complicated change. In Tailwind, I can just look, see "grid-cols-[1fr_2.5rem_auto_2.5rem_1fr]" and know that not only that's where to change it, but that I can also change the classname there without worrying about a regression in some other element somewhere else. Whereas with "card_wrapper card_wrapper--striped", well what controls the grid? I have to look in another file, and I also have to be concerned about every other place those classes are used. (Or I have to add new one-off classnames, at which point the complaint about long classnames holds less weight.)
Personally I prefer how PandaCSS does it - similar end result with atomic css at compile time but it just lets you write your styles as readable objects instead of as insane strings.
Take a guess at what “dark:bg-gray-950”, “bg-white” or “min-h-screen” means. You get them from context.
Imagine if you put a little bit of effort into learning Tailwind. You’d get the more complex declarations as well.
As to why it’s better than a class declaration, a lot has been written about using atomic, composable utility classes over reams of “write-once” class declarations.
I do not disagree that there are one or two recognizable elements in that encoded line-noise. Not sure what is the "terrible take" about it - if you take a poll, most would agree that it requires far too much eye-strain to read, far too much cognitive burden to parse, decode and mentally map to concepts.
Its like deciding to code your entire your app using regexes - all in long single lines without comments.
No one cares what your typography ratio is if you can’t get it in front of a user quickly enough (dead code elimination), reliably enough (type safe), or cost effectively enough (i.e. if you have to pay for more developer time to implement the same work).
Tailwind is a tool for craftspeople, not artists. It democratises design by making it simpler. For folks that are really good designers, they should be happy that they can up their prices knowing that customers are paying for their expert eye, rather than just the basics again and again.
Tailwind does not democratize design. Tailwind is generally 1:1 to CSS, sometimes 1:2 or 1:3. It's such a thin layer over CSS that you have to remember all the CSS. That does not make design easy or hard. You don't give people Tailwind and end up with design as beautiful as ShadCN, even though ShadCN in some perspective is just another wave of stereotypical startup design. The ability to go from blank button to beautiful Tailwind button is all on the author, not the fact that you're writing in a new lightweight inline syntax.
When I read the Tailwind book, my takeaway was their design philosophy was about the speed of iteration and how that interacts with designs whose parameters are too interdependent. Tailwind follows that philosophy by encouraging ad-hoc repeated edits over DRY. In that sense StyleX also fits the Tailwind philosophy very well even though StyleX is an even thinner layer over CSS.
I don’t really agree. You have curated colour palettes, so if you want a red, you’ve got red-50 to red-950, rather than an entire RGB colour space.
Similarly for font sizes, you don’t have to decide on a pixel size, just whether it’s small, large, extra large, etc. Border radii. Border widths. Padding.
There are lots of “sensible” defaults so you don’t have to pick even the units (should I use px or pt or em or rem or vw or ch or…) before we even talk about the numbers associated with those units.
The Reactoring UI book would find whatever structure of defaults given to you as very inadequate for a design system. The book is about an iteration process for creating your own design system. The Tailwind library happens to empower that design process.
But by default there's basically no opinion on what even a button should look like or how colors should be used on your website. You have to create your own abstraction such as "brand-color" and "brand-primary". You have to create your own design system, as there is no Tailwind default button or anything.
If you talk about a default Tailwind look people might be confused and think of ShadCN.
Just because you can build great things with Tailwind doesn’t mean it’s not democratising design. In the same way as putting frets on a guitar helps amateur players make better music without stopping great players doing their thing, Tailwind is the “frets” on CSS that make sure your hands play the right notes. You can still get it wrong, and you can do inspired or uninspiring design with Tailwind, the same as any tool.
Ok fair enough. I was actually talking about the whole of Tailwind rather than just the typography ratios, but I can see how I could be understood in that way. My mistake. Either way, Tailwind works in exactly the way OP describes as their counter example.
Their palette is really neat. I always check it out when I need colour inspiration, especially for "cold greys" and other "state" colours (green for success, red for error, yellow for warning...).
I actually did this for a former company that had a Bootstrap-based app - the designers started bugging that "we need to use Tailwind", and I couldn't figure out why they cared what tech we used.
In talking with them, realized they just were bored with our theme, ha. Not publicly accessible though, sorry. I should probably recreate this.
yeah, the palette is neat. My main gripe with Tailwind is that it blends a set of design tokens (which I like) with a technology to apply them (which I don't like)
Perhaps all the criticism over the years actually had an effect. Or maybe they finally arrived at good conclusions on their own. Either way, I suspect many of the pro/anti-Tailwind arguments are no longer relevant, and that's a Very Good Thing. Now we can get down to business and ship product.