Like most articles complaining about Tailwind, I feel like this one misses the point.
It’s essentially a small language you write in the class attributes of your HTML that compiles to a combination of CSS rules and selectors — an abstraction over CSS.
Yes, I say now on all articles about Tailwind that Tailwind isn’t an alternative to Bootstrap; it’s an alternative to Sass.
The point of Tailwind is just to be a shorthand for writing responsive CSS quickly. If that’s a thing you don’t need, don’t use it.
Unfortunately, Tailwind doesn’t support the perspective property. Implementing any sort of 3D design requires breaking out of Tailwind.
Actually now that there’s the arbitrary CSS feature of Tailwind, you could do <div class="[perspective:1000px]"> etc. but probably you should just write the CSS out in your stylesheet. Why would you want to avoid that? The point of Tailwind is not to keep you from having to write CSS; it’s to let you write CSS more quickly.
You can accomplish the exact same thing without Tailwind by using two properties:
display: flex;column-gap: 0.5rem;
This criticism is weird. You can and should use class="flex gap-2" in Tailwind. The space-x-2 family of classes predate the adoption of flex gap in Safari and are a hacky workaround to it.
Notice the long horizontal scrollbar. This isn’t just an abstraction that leaks some of the underlying details. It’s an abstraction that actively makes the experience worse.
Tailwind is a shorthand. Like all compression schemes, if you make something shorter in one place, you have to make it longer somewhere else to make up for it because of the pidgeonhole principle. Yes, if you’re using lg:[&:nth-child(3)]:hover: as a prefix on each class, it’s much longer than it would otherwise be. OTOH, I would much rather read class="underline font-bold text-blue-600 opacity-100" than
And then use class="lg:[&:nth-child(3)]:hover:random-name" in your HTML, but it’s hard to speculate if that makes sense or not in the abstract. Probably not.
Tailwind is a layer on top of CSS, but it doesn’t actually hide any complexity in the layer below. You still need to know CSS.
If Tailwind were like Bootstrap, this would be a criticism: “Hey, you’re trying to keep me from writing CSS, but now I still have to know CSS to use this thing!”
But Tailwind is not like Bootstrap. The same criticism applied to Sass would seem silly. Sass is just a way to write CSS more easily! Of course you still have to know CSS to use it.
Here are my complaints about Tailwind as someone who uses it and likes it:
The text-* properties are inconsistent. They should all just be property-value, so color-yellow-500 not text-yellow-500. I can never remember how Tailwind does the italics and bold properties for the same reason! They should be style-italic and weight-bold not italic and font-bold.
For that matter, no one needs 1000 possible color slots. 10 is enough! color-yellow-9 Maybe 100 if you want to add room to grow.
The sizes are hard to remember. text-xl should be size-18 instead. max-w-lg should be max-w-128 to be consistent with the 4px scale of margins.
In other words, my complaints are that it should be a more consistent and better shorthand, not that it should somehow hide CSS from me.
I’ve been on two teams that used Tailwind, both moved off once it became obvious it was not worth the effort and simply using CSS was just as good.
I’ve never really understood the attraction of Tailwind, it seems to be good marketing though as I’ve heard designers say stuff like “you can do that in Tailwind right?” and I have to respond with “no, you can do that in CSS, tailwind is just pre-packaged CSS”. It’s basically a slightly larger Tachyons with a bigger learning curve.
There was a time when utility classes were frowned upon everything was shoved in a Sass placeholder or function and it was hard to manage. However, a lot of folks have switched to like 90% utility classes which leads to a different mess. This still requires you know the CSS but also memorize a ton of abbreviations and now other weird syntax to cover nesting?
I’m with you though, CSS as CSS is usually the ideal tool kit for the job. Stick to a naming convention, leverage Grid and variables, and use a few utility classes too.
In my experience, the value of Tailwind (or tailwind-like alternatives (e.g. girouette)) has been for projects that are really “apps” which are incidentally using HTML + CSS as their substrate (i.e. not just web pages). In that case, before Tailwind, we would have to not use the “cascading” part of CSS at all and use almost exclusively direct-child selectors in the style. That made changing things very brittle though, since you would have to change styles when merely adding, say, an extra div. Tailwind works much better for “component” style projects; one can store the classes in variables and co-locate the styles with the component itself.
No. It uses PostCSS, so if you want to run autoprefixer with it, you can, but Tailwind 3 requires CSS variables, so it doesn’t work in IE11 anyway, at which point there aren’t that many quirks to work around.
I believe most people hook into tooling to do that automatically and regardless of frameworks. Autoprefixer was a massive hit. Many tools like lightningcss have it built in. There’s also like flexbugs-fixes or whatever, but increasingly quirks are rarer to come by. The ones still around are often some real legacy stuff that’s 10 years old, or just features that aren’t yet implemented which now @supports can get you across that bridge. Other common patterns like a grid system can be almost completely thrown out as CSS Grid has been adopted by all the major engines for quite some time.
It’s not really a thing any more for run-of-the-mill websites and webapps. It’s definitely still a problem for more complex use-cases, but most of the time I’ve found I and other people I work with on web based products don’t need to care about browser quirks.
Like most articles complaining about Tailwind, I feel like this one misses the point.
Yes, I say now on all articles about Tailwind that Tailwind isn’t an alternative to Bootstrap; it’s an alternative to Sass.
The point of Tailwind is just to be a shorthand for writing responsive CSS quickly. If that’s a thing you don’t need, don’t use it.
Actually now that there’s the arbitrary CSS feature of Tailwind, you could do
<div class="[perspective:1000px]">etc. but probably you should just write the CSS out in your stylesheet. Why would you want to avoid that? The point of Tailwind is not to keep you from having to write CSS; it’s to let you write CSS more quickly.This criticism is weird. You can and should use
class="flex gap-2"in Tailwind. Thespace-x-2family of classes predate the adoption of flex gap in Safari and are a hacky workaround to it.Tailwind is a shorthand. Like all compression schemes, if you make something shorter in one place, you have to make it longer somewhere else to make up for it because of the pidgeonhole principle. Yes, if you’re using
lg:[&:nth-child(3)]:hover:as a prefix on each class, it’s much longer than it would otherwise be. OTOH, I would much rather readclass="underline font-bold text-blue-600 opacity-100"thanThat’s 45 characters vs. at least 90 and much more scannable for me now that I can read Tailwind shorthand.
If you really needed to bundle these properties up for some reason, you could do
And then use
class="lg:[&:nth-child(3)]:hover:random-name"in your HTML, but it’s hard to speculate if that makes sense or not in the abstract. Probably not.If Tailwind were like Bootstrap, this would be a criticism: “Hey, you’re trying to keep me from writing CSS, but now I still have to know CSS to use this thing!”
But Tailwind is not like Bootstrap. The same criticism applied to Sass would seem silly. Sass is just a way to write CSS more easily! Of course you still have to know CSS to use it.
Here are my complaints about Tailwind as someone who uses it and likes it:
text-*properties are inconsistent. They should all just be property-value, socolor-yellow-500nottext-yellow-500. I can never remember how Tailwind does the italics and bold properties for the same reason! They should bestyle-italicandweight-boldnotitalicandfont-bold.color-yellow-9Maybe 100 if you want to add room to grow.text-xlshould besize-18instead.max-w-lgshould bemax-w-128to be consistent with the 4px scale of margins.In other words, my complaints are that it should be a more consistent and better shorthand, not that it should somehow hide CSS from me.
mate, you’ve done an excellent job describing the case for using Tailwind CSS.
p.s. I used to refrain/sway-away from it for a quite some time. However, once I adopted it, it’s definitely helping with my CSS/design productivity.
p.p.s. I’m using a “good balance” of custom classes (with @apply) + the stock inline classes.
I’ve been on two teams that used Tailwind, both moved off once it became obvious it was not worth the effort and simply using CSS was just as good.
I’ve never really understood the attraction of Tailwind, it seems to be good marketing though as I’ve heard designers say stuff like “you can do that in Tailwind right?” and I have to respond with “no, you can do that in CSS, tailwind is just pre-packaged CSS”. It’s basically a slightly larger Tachyons with a bigger learning curve.
There was a time when utility classes were frowned upon everything was shoved in a Sass placeholder or function and it was hard to manage. However, a lot of folks have switched to like 90% utility classes which leads to a different mess. This still requires you know the CSS but also memorize a ton of abbreviations and now other weird syntax to cover nesting?
I’m with you though, CSS as CSS is usually the ideal tool kit for the job. Stick to a naming convention, leverage Grid and variables, and use a few utility classes too.
In my experience, the value of Tailwind (or tailwind-like alternatives (e.g. girouette)) has been for projects that are really “apps” which are incidentally using HTML + CSS as their substrate (i.e. not just web pages). In that case, before Tailwind, we would have to not use the “cascading” part of CSS at all and use almost exclusively direct-child selectors in the style. That made changing things very brittle though, since you would have to change styles when merely adding, say, an extra div. Tailwind works much better for “component” style projects; one can store the classes in variables and co-locate the styles with the component itself.
Does Tailwind help to work around browser specific quirks? Though I don’t know if that’s still a thing for web front-end developers.
No. It uses PostCSS, so if you want to run autoprefixer with it, you can, but Tailwind 3 requires CSS variables, so it doesn’t work in IE11 anyway, at which point there aren’t that many quirks to work around.
I believe most people hook into tooling to do that automatically and regardless of frameworks. Autoprefixer was a massive hit. Many tools like lightningcss have it built in. There’s also like flexbugs-fixes or whatever, but increasingly quirks are rarer to come by. The ones still around are often some real legacy stuff that’s 10 years old, or just features that aren’t yet implemented which now
@supportscan get you across that bridge. Other common patterns like a grid system can be almost completely thrown out as CSS Grid has been adopted by all the major engines for quite some time.It’s not really a thing any more for run-of-the-mill websites and webapps. It’s definitely still a problem for more complex use-cases, but most of the time I’ve found I and other people I work with on web based products don’t need to care about browser quirks.