I've really seen Tailwinds take off lately in "marketshare" as well as "love-share".
On the other hand, the CSS ecosystem has been in mayhem for years...
Article No Longer Available
I find the Tailwinds utility-first approach to be a really pleasant way to work with CSS, and CSS and pleasant are rarely used together in a sentence.
...But we've been here before in so many ways. I'd love to get folks' opinions on the CSS space.
Top comments (60)
Some good feedback came out of this post.
What are your thoughts on Tailwind CSS?
Nick Taylor (he/him) ・ Jan 27 ・ 1 min read
TLDR in the comments in that post seems to be you either love it or hate it.
Why tailwind is better than bootstrap ?
You can't compare tailwind with bootstrap . Tailwind is a utility first framework, which does not give you ready-to-use components. Bootstrap mostly gives you ready-to-use components.
on the other hand bootstrap has this aspect of css utilities. So you can take out only the scss of bootstrap and use it with whatever react / angular / whatever framework and you get the quite decent bootstrap styling. Only by reusing their css vocabulary.
Here's my two cents (rounded to a nickel since Canadian pennies are no more...):
Tailwind is super useful as opposed to a lot of other frameworks, IMO, because it doesn't have a pre-determined philosophy. Bootstrap/Foundation/Bulma/Materialize/Vuetify & co. say "this is a button" or "this is a navigation drawer."
That kind of paradigm is useful when you don't have those ideas floating around in your head already, or you like the way they do it. But what if you want to change the margins, padding, font size, or what have you of one of those components? I'm working with Vuetify right now, and I can say first-hand that that annoyingly means a lot of
!importants in my CSS...Tailwind (other than the new Tailwind UI, which looks intriguing) is basically just like writing CSS, except most of the normal/mundane things have an easy class (that doesn't come with any side-effects, baggage, or other styles). Want to have a button get bigger on hover? Add
transform hover:scale-105to the classes. Boom. Done.But it doesn't replace CSS, in my opinion. There are some things you just can't break down into reusable classes like that. Like animations, or custom media queries (though Tailwind does come with an ample amount of customization for the latter), or - dare I say - some kind of browser hack to fix that annoying little glitch that happens to the hover styles on last year's version of Chrome...
To me, SASS is the future of CSS, but Tailwind means you can write less Sass, especially for reusable things.
Though, it has its limits. One is fairly obvious; you're still writing a whole bunch of styles, just not in the style block, but right in the HTML. You can easily get a class list that takes up several lines, or trails off beyond the horizon of your editor like a minified, inline SVG. Tailwind does use the
@applydirective of Sass to apply a lot of stuff as mixins, so that can be avoided to some extent.The other, of course, as already mentioned by my fellow commenters, is that you really need PurgeCSS or something like it when you're using Tailwind. It just adds a bunch of mostly-unused bloat to your bundle size otherwise (to the tune of a few hundred kilos, if you aren't careful - and even sometimes if you are). And, at least for me, Purge is almost more trouble than it's worth. Almost.
Bottom line here is that it isn't a magic bullet. It solves a ton of problems, but it introduces a ton of potential challenges. At the end of the day, you can't really beat proper modularization (via Sass or scoped styles in Vue components or what have you, perhaps) of styles and class naming conventions that make sense. Tailwind brings a lot to the table, sure, but it really brings a lot (by way of overhead and build process shenanigans). It ain't magic, folks (but if you like it, you'll really like it).
Just a minor thing, but I believe Tailwind's
@applyis a PostCSS directive, even if Sass provided that directive first.Definitely agree something like Purgecss is needed. Love Tailwind, but I'd have a hard time shrinking my production CSS otherwise with the shear number of variants.
You're right, of course (since Tailwind needs PostCSS to function properly for most applications). I use Nuxt, so I'm used to over-abstraction to the point where "it just works", so I tend to forget where things actually come from.
Nuxt is pretty awesome too (even though I haven't gotten to use it extensively yet). Love Vue!
Also, no worries. Was mainly mentioning for others who would read. I'm really glad Tw has this directive too. I haven't yet, but I have some Vue components I'm thinking of taking the Tw classes from and turning into CSS components—small things that make sense now that I've used Tw on this one project for a while. This directive will really come in handy in this case.
PurgeCSS is a must with tailwind. They actually added it as a built in feature in the latest release so it's super easy to get it up and running now.
I think this actually gives them a one-up on bootstrap now too as it does now mean that the out of the box compiled production css is far smaller than bootstraps.
Ah, I see! Thanks for the heads-up (I've been using 1.3, so I didn't catch that update). You got a point there; Tailwind + Purge (especially now that there's first-party support for the integration) is a winning combination.
This is a pretty balanced take on it.
I agree with this especially: To me, SASS is the future of CSS, but Tailwind means you can write less Sass, especially for reusable things.
I think the way forward would be to write high-level SASS mixins (say, 'content-column') on top of low-level ones (say 'content-margin' and 'body-text'), and then once some of the high-level ones are used widely across an app, you could promote them to utilities like Tailwind's.
This would give you a good compromise: readable markup, centralized rules, a separation between component and utility, and last, it would save some duplication in the generated CSS.
I almost never do any frontend stuff, mostly backend or native Android, but with tailwindcss I was able to quickly throw together a nice design that was build responsive without needing to write a single line of CSS myself.
Adam Wathan (tailwindcss creator) is also taking this to the next level and looking for 2 people to join him fulltime.
Backend with same experience here.
I'm working on something personal and Tailwind saved me the work to write lots of styles I didn't have enough idea of.
It's simpler than Bootstrap (which is my default many times) and easier to use.
I think the idea of
utility first approachis the way forward. This gives flexibility to the engineers to build UI's how ever they choose while leveraging the power of the utility. The utility updating under the hood allows to better browser support.I think atomic/utility/functional css is an interesting approach in writing css that was mostly misunderstood until tailwindcss came out with this specific implementation. It mostly makes styling components faster and frontend developers love it. On top of that can reduce the amount of the final css send to the browser and can benefit website/apps of any size. Facebook recently anounced how their new atomic css approach has reduced their css by even 80%.
I think tailwind it is here to stay and perhaps more frameworks will follow this paradigm.
I would take the "Facebook reduced their CSS by 80%" point with a grain of salt.
There is no hard rule saying that atomic CSS will reduce your CSS by a large amount. It all depends on how the CSS was written in the first place (not to mention how the counting was done).
Imagine FB has 300 engineers working their UI (I don't really know). It's very likely that a lot of them will repeat the same code (BTW, this is what brought Nicole Sullivan to come up with OOCSS back in the day), and atomic CSS is likely to have a big impact here because there is so much CSS in the first place.
But on smaller teams, with 4 devs who know what they're doing? I'd be surprised if we saw more than a 15% reduction.
All of this is opinion, and I have no data to back it up, but I don't think this is a crazy argument.
Yes I usually take everything with a grain of salt. I am just pointing out the possibility and facebook example shows that if carefully planned we can have big reductions in css size.
In the case of tailwind the integrated purgecss plugin can help us reduce the css size but it is not always possible to actually use it and in those cases tailwind should be avoided or manual optimizations should be employed. Purgecss usually needs to scan all pages to see classes used to eliminate the unused ones which is not always possible especially on dynamic sites.
I believe will see tools and platforms finding ways to feed the used classes to purgecss to take advantage of tailwind powers. This is usually a painpoint of integrating tailwind with any existing platform/framework/project.
For me the main point from the facebok article in regards to css is that they addressed this by generating atomic CSS at build time. It would be nice if they open sourced this tool. Either way at least it has given food for thought to many excellent engineers to think of ways to do the same and will be seeing similar approaches very soon.
Funny article where Facebook announces to the world they've discovered this new framework called React and they used it for their home page.
Though to me the only lesson we can get from there is that they trashed 16 years of legacy code written between vodka shots in order to use more modern practices and it improved a bit. I wouldn't draw any conclusion towards "atomic CSS" or Tailwind.
I agree with this.
If Tailwind doesn't provide the utility class to do something, what's the recommended way to solve this? For example, adding a background image or add styles to a
:beforeor:afterpseudo element. Should you add a custom class?That's where in my opinion these CSS frameworks fall short. They promise that styles are in 1 place (your HTML), but if you have to build a highly custom pixel-perfect responsive design you have to violate the principles they are based on.
Personally, tailwind has opacity-25, opacity-50, opacity-75, but in this case I really wanted opacity-90. Usually when I'm confronted with cases like that I mostly just add that to my custom css.
The tailwind way of thinking is really useful.
I have gone through all the phases, I started with my own styles with CSS, I went through LESS, I tried with Bootstrap 3 and 4, then I moved to SASS to be able to create the class libraries in the companies I worked with and I stayed there. A new design would come and I would layout and add my named classes in BEM.
And suddenly, PAM, utility-first and I said 'wow, this is not going to be better than my own styles' and I start reading and discover that what I added in the inspector as property-value to add to my SASS class, now it's a class I can add in my HTML and the magic is done.
Honestly, I understand that there are projects that don't fit with this technology for x reasons, but my productivity has increased a minimum of 75% since I use TaiwanindCSS, I just can't love them more 😍
Big step forward. Quoting myself from my reply to Nick Taylor's post:
I think Tailwind has its place in very large, complicated web projects. You don't have to worry about the size and scalability of your stylesheet ever again.
However, it's not without drawbacks
The first is the added complexity. Tailwind isn't usable without Purging. You have to have a proper setup for your tailwind config, postcss, purge, and whetever your need in between. Setting up takes time and requires maintenance, especially as dependencies change.
Want to go crazy with wild grid layouts? Animation? Next-gen properties? You'll have to implement them in Tailwind by hand first, which kinda defies its reason. Do that a lot, and you'll soon feel like you're constantly fighting against your CSS framework.
I'll play bad cop here because everyone seems to be playing good cop :)
"as a backend dev, I can do CSS!"
So you can't write plain CSS but Tailwind works for you. Great news, more productivity is a good thing!
But you still had to read Tailwind's doc and learn it, right? I'm guessing you chose that route because it felt less daunting than learning CSS from scratch. Could it be that a good part of the value you're getting is rooted in Tailwind's high quality docs that make it easy to learn? Compare that to CSS which does not really have a central place to learn? (check out every layout if you're learning layout).
So to sum up: great if it helps you, but please learn CSS. Tailwind can be a great path to learning it in a "safe" way.
"naming is hard".
I am both sad and angry that this is a thing that people bring up. I would argue that if you can't come up with a class name for an element, maybe it's not clear to you why it exists? Maybe it's an extra div you don't need? Usually when you write lean markup, names just spring at you. And... the author does not even bring this up! Let's forget about this one, it's more of a footnote than an argument.
"atomic CSS is the future"
I agree that 5 years from now, atomic CSS will still exist and will still be going strong. But I guarantee you most people won't be using it. This is opinion of course, but so is the other argument.
I don't quite see why we can't move the utility approach to SASS mixins and keep the composition in *.scss files. This would be a good compromise IMHO. Yes this will lead to a little bit more code duplication in the CSS sent down the pipes, but Gzip is your friend, and...
I don't buy the "huge reduction in CSS" (see Facebook's recent post) argument. I think it won't lead to the same huge reduction in most teams with fewer devs and a lot less CSS. The total sum of my CSS bundles is in the 60KB range. That's not enough to cause me to question how I write CSS. It is for Facebook, but how many people are playing at their level?
;)
This.