I've really seen Tailwinds take off lately in "marketshare" as well as "love-share".
Why I fell in love wit...
For further actions, you may consider blocking this person and/or reporting abuse
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.
My comment in Nick Taylor's post gives some background on what problems TailwindCSS tries to solve (spoiler! it's not trying to be the solution for every site/application).
Adam Wathan, the maintainer of TailwindCSS, wrote an article a couple years ago about the differences in CSS architecture that exist between traditional approaches (BEM, SMACSS) and atomic/utility approaches.
Here's that article: adamwathan.me/css-utility-classes-...
I recommend everyone read it.
Adam doesn't declare that one approach is bad and another is good. Instead he provides insight into what the constraints are of each and what use-cases each might be good for.
In the end he argues that most of the sites/apps he works on benefit from the approach provided by TailwindCSS and other similar libraries (Bulma, Tachyons, even Bootstrap's utility classes).
I think understanding why we should use TailwindCSS is as important (or more) as asking the question "does Tailwind make me more productive?"
And yes, I like TailwindCSS because it fits the type of work that I find myself regularly doing.
I think the key thought in the blog post from Adam Wathan (that I linked to in my other comment) is this (emphasis is Adam's):
<div>, compared to the entirety of CSS. (We are freed to be creative through our constraints).Thanks for sharing!
I do agry on not componentizing/abstracting too early and I have been a huge user of bootstrap utility-class… only to move away from it all over again.
When you have to maintain your app, you definitely don't want to be chasing if every single spacing utility has been changed correctly. A coherent system of named components greatly helps in that.
That's a great point and an issue I've run into myself.
The Pros of this approach are also the Cons! 😁
If I use these utility classes to style my markup, then I can change markup and classes in one part of the app without worrying about regressions somewhere else.
The utility class approach is resistant to unintended changes, which is a great feature 💪!
However, if I want to make the same change across the entire app, I'm going to have to do that manually because the utility class approach is resistant to intended changes, which means more work for me ☹.
So here's a question worth considering - what's more important to you, preventing regressions or refactoring quickly 🤔?
The answer to this question needs to be balanced with the other pros/cons of utility based classes already detailed.
One thing I've found helps mitigate the refactoring cost of utility based classes is componentization, not at the CSS level, but at the HTML level.
Client-side JavaScript frameworks (and even some server-side templating languages) excel at this. They are able to group blocks of reusable HTML into a 'component', which means some app-wide changes can be made in a single location.
Thanks for bringing up the original article again. I read it back then, and seeing how popular Tailwind has become, it's good to see what prompted it in the first place.
Going down the article, you can't really help but be convinced that he's on to something.
My personal theory is that Tailwind is a joke that nobody really caught.
A few arguments:
classinstead of<style>well so be it but you're still writing it.class?I'll sum this up that way: if you can't document it, why even bother using it?
Tailwind is more than a joke. It's a terrible joke.
I can't wait for tailwind to mature a little bit more. Tailwind feels like it really allows you to leverage the power of css without so much of the pain of following arcane naming rules, getting stuck into a framework, or not knowing what is going on with your styling.
It's very fast for solo building, but I have my doubts for long term maintenance, especially in a team.
If you don't use a some sort of component based approach, when you need to change the padding of every type of card, you're good to find them all by hand.
Even if you do code in components, some might be different but inherits common properties—cards padding still is the good candidate. Then again, you are good to find them all by hand, with no guarantee that everything with
px-4is a card.And when coding components with scoped styles (Vue/Svelte…), I hardly use classes at all anyways, even utilities. Selectors are most often tags or ids. Values are either obvious, either some gobal variables.
Now the problem of coding in component has been known for years and is mostly tackled since bootstrap popularized it—altough… surprises. The problem of overall coherence and DRYness is solved with global settings and global classes as popularized by… yeah Boostrap.
I actually often end up rebuilding my little Boostrap from the bottom up everytime. First, do things in components with stupid selectors. Then, whenever you feel you are repeating yourself (colors, spacing, global class…) create a global class or variable. And voilà. It's just as fast, but much more guaranted to be coherent. I guess that makes me in the Sass camp?
Last one for the road: one more config file!🎉 _package.json, eslintrc, webpackconfilg, nuxtconfig, now/firebase _… and now tailwindconfig with it's very own fleet of arrays. Who said convention ? 😇
I think it's a medium-sized step backwards.
I mean, it's only a small step backwards, but I'm setting it to "medium" since it's getting more momentum for some reason.
I think it's another example of people doing exactly the wrong thing. I guess it ties in relatively neatly with CSS-in-JS and all the other things I think are badong.
The only way that putting your style in your markup is ever going to help is if in the future we have AIs to do all this for us. Because it's back-to-front. It's worse for everyone.
Big step forward. I just wish there were more alternatives.
Funny thing is, even though I mostly use Bootstrap I already sort of use the "Tailwind approach" a bit, so instead of writing heaps of CSS I'd use smaller utility classes (some provided by Bootstrap, some hand-written) and apply those to an element, like so:
<button class="btn ml-5 mr-5 d-flex justify-content-center my-style-1 my-effect-2 my-blabla-3">...Tailwind goes a lot further (not even having a built-in 'btn' style) but you get the idea. It's just more flexible than writing specialized CSS for every element under the sun.
Yup, I really enjoy it. In fact I just put this out for anyone who wants to learn it or is skeptical about it:
Tailwind CSS for skeptics - Interactive Tailwind CSS tutorial
Michael Z ・ May 17 ・ 1 min read
I have never used Tailwind but I agree bootstrap is kinda overkill.
True. Bootstrap is for CSS what JQuery is for JavaScript. They had their moment indeed, and now they are fading way :P
When you write a custom class, do you use a single custom class and use
@applyto apply all the tailwind styles? Or do you only write the custom styles and keep the other classes?And what's the naming convention for these custom classes?
I've been trying Tailwind for a while now and in most cases it's quite nice.
It's quite quick to do basic layouts etc... but...
It doesn't replace CSS, as mentioned elsewhere. So you still have to rely on "normal" css to get the other details sorted out.
Now the problem I find with this approach is that now there's css in the html and in the css sections of the components Plus css in the global css files.... aaargh
I don't use Tailwind but I understand the appeal. Many people can create something that looks nice without needing to know heaps of CSS. That's very powerful. But it comes with its drawbacks. For me, the biggest one is the abstraction.
Personally, I'm comfortable with CSS and I would prefer to write it myself. It's going to be around forever, so I might as well master it 🙂
I still stand by my articles that I've written that I really really like tailwind.
Combining a component system with utility css works really well.
Tailwinds constrained set of choices gives you the flexibility of choice but forces you to be consistent in your design.
You can get a great looking site with essentially no bloat especially now that purgecss is built right in.
I don't see myself not using a utility first css system going forward.
I really enjoy using Tailwind when a totally custom design is called for. I like using Bootstrap when I don't feel like designing and just buy into its design patterns (which I think are great).
That said, Tailwind is killer when combined with a component-based front end like Mithril, Vue, React, Laravel Blade, etc. Just change a class in a component instead of dealing with CSS/SASS/PostCSS mess.
In my opinion Tailwind is a big step in the right direction.
Not everyone is comfortable with CSS and the utility approach is a good way to mitigate those shortcomings, enabling them to develop and prototype responsive and clean UI faster, while allowing more experienced users to have a solid foundation to work and extend on.
To answer the question: I think Tailwind is here to stay. I put it in the same boat as other CSS frameworks like Bootstrap and Bulma.
It has a good advantage because its styles are quite specific and utility-like, which allows us to style things any way we want. In comparison, something like Bootstrap provides classes for components and not many utility classes. To modify components further, we need to write our own CSS. Of course the downside of Tailwind CSS is that because each class provides less styles, we need more of them in our HTML.
So it has pros and cons, as with anything, but it's a great option to have. It's my preferred choice for a CSS framework.
However, I still strongly believe that something like BEM is more suitable for larger projects that value scalability, robustness and pixel-perfect designs.
Absolutely love it! The main benefit, for me, is that the classnames are consistent. You can apply consistent classes to abstract the inconsistent css rules.
I like to compare it to the difference between Vue/AngularJS templates and jQuery. jQuery hides all the logic in scripts that can be who knows where. CSS can obviously be inline, but it's often hidden away in giant stylesheets. Tailwind pulls that obscured styling and makes it very obvious. Making development and debugging much easier and quicker.
Utility-first css (aka atomic css, aka functional css) is something that exists way before tailwind. The first framework built on top of this approach was AtomicCSS in 2015 and thi approach can’t replace the OOCSS, you can see it even on the tailwind documentation examples. You end using both approaches very often due to its limitations.
Said that tailwind requires a specific build process when used inside not-static projects like react, vue or svelte because purge CSS needs to be configured to remove tailwind’s dead code from dynamically generated dom (and doesn’t works well).
Also atomic CSS, and so Tailwind, follow opposite paradigms than any modern component-based framework.
it’s a good tool like many other CSS frameworks made in the last 5/6 years, but only for static HTML projects. They are just another useless abstraction layer and tools to be configured when building component-based projects that introduce more appropriate tools (CSS modules, CSS-in-components, scoping)
Just another thing. Get your responsive class names out of my HTML! If you have to declare your template with metadata, fine this could be an alright approach, but otherwise keep all responsiveness in CSS. The mental model to understand how Tailwind class names effect styling is too difficult, especially when they are chained. It is not difficult to wrangle media queries. All the bloat to the HTML will add up in complex layouts.
My favorite CSS framework of all time is bourbon. Bourbon was just another thing too. Bourbon is just a bunch of utility SCSS mixins, which abstracted our CSS nicely and meant we didn’t have to reinvent the wheel for most things. Progress has made Bourbon somewhat obsolete over time. I’d like to see more of that: preprocessor frameworks coming up with abstractions around common tasks.
Its a big step forward for performance freaks. Styles can be XX times smaller than originally and the risk of unused css/bloat is heavily minimized.
Also, its a good opportunity to get rid off weird dependencies like sass, in favor of postcss plugins.
At least that was the case for our documentation site. It was a pleasure to migrate to.
my two cents:
I think the vocabulary in tailwind is quite extensive. So that a higher entry barrier than e.g. with bootstrap (the css only part of bootstrap). However, for very common and straight forward websites that might fit perfectly it's place. In enterprise applications very often you end up writing pretty custom css, where the tailwind approach would be totally counter practicable.
Also personally I'd like to keep my markup clean, but with tailwind I'm ending up with 'polluted' markup where the styles detail are basically everywhere. So shuffling around the layout e.g. with css themes, without markup changes, becomes pretty hard.
I've had a bit of a rollercoaster ride with Tailwind.
When it initially came out I immediately dismissed it. Bootstrap 4 was easy, quick and required little effort. It also helped that I'd used it so much that I rarely had to look anything up in the documentation.
However I started a new project with a friend and we needed a super simple website (2 pages), so I decided to give it a shot. It was a slow process but I 'got it' and realised what it was trying to do. Bearing in mind I'd never really used a utility framework at this time.
The site was pretty rough but was surprisingly quick to put together.
I stuck with it for a few more, and I don't think I'd go back to bootstrap now.
It has it's obvious downside - there's no big library of free components (at least not an official one, I spotted this on product hunt a few days back and it looks pretty cool) and the community isn't anywhere near as big as bootstraps. But I think it has its place.
One thing that I am liking is the commitment shown by Adam (creator). He's obviously made a fortune out of TailwindUI, which now means he can afford to hire people to work on it full time. To me this shows that he's committed to making Tailwind a serious competitor, which is never going to be a bad thing.
Anyway, fast forward a year or so, I've just redone that original site (link) to launch my product and it took around 3 hours to put together in total.
At first I thought it was great, but then I saw the bloat arising from templates, quickly becoming unreadable. The flow I use while reading other people's components is to first understand what the template says, then switch to the style if needed, then switch to the logic and start moving back and forth. Tailwind tries to squash the styling into the template and the time it saves while using it is proportional to the extra time someone else will spend on debugging it. I don't like stuffing the templates because people don't want to learn CSS.
Also, PostCSS is a must if you plan on using Tailwind on production and I can say it's pretty demanding to set up, especially with Angular.
TL;DR: what's the point of moving inline-like styling into templates? Time supposedly saved is then doubled while debugging/refactoring. My 2 cents
Well, anything that will make CSS easy is welcome.
I think it might be bootstrap killer?
Love it. I do understand some of the drawbacks (e.g. hard to read class names), however they do have a solution for that too. In general it's helped me become a better designer 🙏
That's exactly my point. Writing new extensions just to be able to write normal CSS is fighting the framework.
I'm not sold on Tailwind tbh. I also see classless css approaches too, meh.