Classic rock, Mario Kart, and why we can’t agree on Tailwind
joshcollinsworth.com
joshcollinsworth.com
Today's "Tailwind-in-HTML" is tomorrow's tech debt on a scale we haven't seen since the AngularJS days from a decade ago.
It won't be pretty.
(But perhaps a future job opportunity for folks who can rebuild design systems using real CSS and web standards.)
But I might just be naive.
The analogy didn't reflect my experience either.
IMO, Tailwind is a coping strategy for people who have accepted that CSS is bad technology. The Cascade seemed like a good idea at the time, and made for some cool demos back in the "CSS Zen Garden" days, but in practice it is miserable to work with; it's even less suitable now that most websites are assembled from self-contained components. But it's what we have, and at least Tailwind makes it fast to build and modify things.
Most teams do not have a dedicated designer. Most developers are quite bad at CSS. These teams, which are most teams, want to ship something that is not butt-ugly and do it fast.
That's what Bootstrap did and what Tailwind does. All the endless discussions about the technical merit of inlining utility classes versus hand-crafting CSS are pointless and cannot be resolved because they miss the point entirely.
The point is: ship something good-looking very fast by people that suck at UI or don't have proper time for it.
Tailwind is basically just a DSL for CSS. You write these Tailwind classes like "pl-4" or "items-center" and the compiler converts these into real CSS like "padding-left: 16px" or "align-items: center". You can even write arbitrary CSS using square brackets, although the syntax starts getting a bit messier: "pl-[33%]" will convert to "padding-left: 33%", so you really can use whatever arbitrary units and styles you want. So no, it's not particularly like Bootstrap, because Bootstrap is a set of predetermined base styles and components, whereas Tailwind is just a DSL for doing whatever you want to do in CSS but in a different syntax.
There is a similarity in that Tailwind provides a number of default lengths, colours, etc for you to use - the "2" in "p-2". These can be used as-is, although in most serious projects, you'll end up adjusting these based on the standard widths coming from your designer. So for example, you might have a 5px scale, in which p-1 represents a scale of 5px, p-2 is 10px, etc. In this sense, Tailwind is reminiscent of CSS frameworks like Bootstrap, but it's more similar to using CSS variables, or having a set of SCSS theme variables - you can use these values in a variety of ways, and there's always the opportunity to just use the raw CSS value syntax with the square brackets.
Specifically with the grid example, Tailwind doesn't come with any grid baked in, but you can easily access flexbox (e.g. "flex flex-column items-end" for a vertical flex with items aligned at the end), or CSS grid as you need them, so you're using all the tricks of modern CSS that you'd expect, including very flexible, resizeable layouts.
It really helps to think of Tailwind as just a DSL for CSS-in-HTML. Anything you can write with CSS, you can write with Tailwind, just differently. As to whether you need that DSL, it mainly comes down to how separate you want your CSS from your templates. In my experience, the further away my CSS is from my templates, the more like spaghetti they become, so keeping them close together helps a lot. And for deduplication, I can just use whatever tools I was using to deduplicate my HTML - partials, components, loops, etc.
(That said, I tend to find that I prefer writing CSS modules, although I do tend to create lots of utility classes there so that I can have consistent padding widths/colours, etc, so my CSS tends to have a bit of a Tailwind vibe to it.)
If you already know CSS inside and out, they’re nothing but hurdles, someone else’s code maddness you must learn the method to in order to contribute.
Tailwind is really just a DSL over CSS. Which means you need to know and understand CSS to write it. The syntax is perhaps marginally simpler, although it has its own complexities. The biggest thing you no longer need to worry about is selector specificity, but even that's something I rarely worried about in the first place in CSS.
Everything else - the cascade, the attributes, the units, pseudo-classes, and so on - are all present in Tailwind, and you still need to understand what's going on to use it. And because Tailwind is mostly just a relatively transparent layer over CSS, all your CSS knowledge still applies. So you're not using "someone else's code", because in writing Tailwind styles, you're just writing CSS in a different syntax.
(Whether or not you need that different syntax is another story, and that mainly comes down to how much you use components and partials in your HTML authoring. If you work quite hard on deduplicating your HTML, then Tailwind is useful because your styles end up deduplicated for free alongside the HTML. If you tend to use HTML directly as your content authoring tool, then Tailwind leads to a lot of duplication, and you probably want to use CSS directly.
Extremely useful when building out a design system for the first time.
There are two problems with tailwind; 1) https://twitter.com/dillonchanis/status/1706473840367247482/... and B) the tailwind fan boys.
Every project of any decent size needs utility classes. No reason not to use tailwind for those. But every time I head that naming things is hard, I can't take that person seriously. You're not naming a baby. and if you change your mind on .pricing__card__header, just use your editors refactoring tools to rename it.
And yes, I am looking at you, Mom... ;)
@apply and the frowned upon solution is what I would expect to be the only clean solution.
I am a proponent of WET, but pulling the naming things card when it comes to places that you may want to localize, test or aria-label anyway, just seems lazy to me.
There's also a difference between naming things of actual significance, which as you say may need to be localized, labeled, etc. and having to name arbitrary CSS junk like .button--state--success, which is painfully annoying. Type it up in the CSS file, switch over to the markup file (another annoyance that Tailwind helps you avoid), paste it in, repeat.
I think it happens eventually with most of code, whatever language. If you don't have a clear structure or methodology at the time of writing it, it will become a mess at some point. I don't think it's a particular problem of CSS.
So that unveils me as a "crafter" - well, am a graphic designer doing CSS since 2006 or so; in fact I've thought that way about doing 'raw' CSS, that is the most "artisanal" thing one can do in the world of web dev - and whereas it is true Tailwind can save time in styling a web page or whatever, it takes away from the expresiveness of doing it "by hand". Many people even here wonder from time to time why contemporary websites pretty much look the same: many people are using frameworks to style them.
It's kind of something like doing your own furniture in a pretty artisanal way vs. getting something from Ikea. Or more like growing your own potatoes vs. buying processed potatoes at a mall. You'll end with potatoes in your stomach, but they will taste differently.
Not if you lint your CSS with rules preventing these kind of things. The same is true for maintainability. Stylelint is a great tool for that.
Component libraries suck when you need to massage a design system into them. But at least half the arguments over Tailwind vs CSS are devs mostly doing their own thing and touting how easy it is to change X Y and Z. Similarly those same devs hate component libraries because you can't just change X without changing X everywhere.
_
A little secret they don't realize is, X changed everywhere so that your site wouldn't look like a pile of slop.
That's why even the darling of the "anti-component-library pro-ctrl+c-ctrl+v establishment" shadcn/ui had to go back and add theming and a component.json.
If not using a component library is easier for you, that's a red flag: the alternative should be your team rolled out their own design system, and that's just a different kind of difficult with a different set of trade offs.
If you're using a design system, I don't think CSS vs Tailwind is as much of a mortal conflict because the design system provides a map. Usually that map gets translated into something like variables, or even Tailwind Variants, and suddenly the biggest issue with Tailwind (scattering consistent properties across the codebase) is not as terrible as it seemed.
Sure. You can punch tailwind until it behaves like the formatting templates people used on PHP before CSS generalized them. This will indeed fix the problem.
The only thing I got to say is "blegh". You are adding code to get the "90's-dynamic" behavior into a framework that added code to remove the cascading behavior from the framework that came with code to emulate the "90's-dynamic" behavior with a few extra bonuses.
But yeah, it works. I have no idea why one would choose to go that way, but if one is constrained into it, that's a sound direction.
What is the difference between Tailwind and in-line CSS?
> Often the biggest challenge when working with a framework is figuring out what you’re supposed to do when there’s something you need that the framework doesn’t handle for you.
[1] https://tailwindcss.com/docs/adding-custom-styles#using-css-...
Tailwind works pretty well for us.
Shameless blog link: https://medium.com/teutonic-css/retiring-my-own-little-css-f...