Is TailwindCSS worth it? Tailwind is a utility CSS framework that depends on the developers using it to also know a little CSS. It is lightly opinionated but simple. Do these points together make it harder to use for unfamiliar developers?
Since Tailwind is a utility CSS framework it means that every provided class is a utility. These utilities range from text formatting to flex-box management and more. ex:
flex flex-row justify-center
This is fine. But did you notice these classes are familiar? I mean really look at them. They look like plain old CSS without the extra hassle! For example:
display: flex; flex-direction: row; justify-content: center;
becomes
flex flex-row justify-center
You may be asking yourself how this could possibly be useful. You might even be telling yourself that you could save the learning curve and just write plain CSS inline or in a stylesheet. That might be true. But you would be missing the point of Tailwind and the problems it solves. These near plain old CSS like classes can actually be used to solve many problems that regular development faces such as rapid prototyping and effects.
Let's build a simple card example for those Bootstrap fans out there to demonstrate how powerful Tailwind can be. (Yes. I know you exist and overuse the card component regularly.) We will show the source for the card with inline CSS and Tailwind. This should enable you to see the difference.
<div class="w-1/3 mx-auto my-2 shadow-sm rounded-lg">
<div class="bg-gray-100 text-gray-600 px-3 py-2 text-lg font-semibold rounded-t-lg">Header</div>
<div class="bg-white text-gray-600 p-3 rounded-b-lg">
This is a card example in Tailwind CSS.
</div>
</div>
<div style="width: 33.33%; margin: 1rem auto; box-shadow: 0 1px 2px 0 rgba(0, 0, 0, 0.05); border-radius: 7.5px;">
<div style="background-color: #f4f5f7; color: #4b5563; padding: .6rem .75rem; font-weight: 520; font-size: 1.1rem; border-top-left-radius: 7.5px; border-top-right-radius: 7.5px;">Header</div>
<div style="background-color: white; color: #4b5563; padding: .75rem; border-bottom-left-radius: 7.5px; border-bottom-right-radius: 7.5px;">This is a card example in inline CSS.</div>
</div>
This renders into the image below:
Okay. So Tailwind does save a little time and overhead if you are writing everything inline. But this is not maintainable! How are you supposed to update your site if you have to go into every tag and update it? Well Tailwind is meant for you to rapidly prototype like we did above and then convert to actual semantic CSS classes. If you have ever used other CSS Frameworks or written your own classes you will recognize them as
.card {}
Tailwind provides a utility if installed using NPM that allows you to compile all those styles you prototyped with into semantic CSS. Please follow this guide to understand how we get here. Once you have read this guide then continue reading! Or continue if you are already familiar with the TailwindCSS installation and setup.
Once we have our prototyped components we can easily convert them into simple to use classes. All you have to do is name your semantic class and drop in everything inside your "class" tag. Ex:
.card {
@apply "mx-auto my-2 shadow-sm rounded-lg";
}
.card-header {
@apply "bg-gray-100 text-gray-600 px-3 py-2 text-lg font-semibold rounded-t-lg";
}
.card-body {
@apply "bg-white text-gray-600 p-3 rounded-b-lg";
}
With our new semantic CSS classes we can now convert our component! Just replace those long utility class-lists with your semantic class. Ex:
<div class="w-1/3 card">
<div class="card-header">Header</div>
<div class="card-body">
This is a card example in Tailwind CSS.
</div>
</div>
Wow! That is so much cleaner! Once you get to know how Tailwind is supposed to be used and have practiced it you can quickly see why Tailwind is worth it! It can save you time on larger design projects while empowering you to convert back to semantic CSS classes painlessly! Tailwind is also powerful for those not very familiar with plain old CSS as it cuts down on the overhead statements such as "flex-direction: row" and makes it as simple as "flex-row"!
Tailwinds learning curve is in my opinion simpler for those who have little to no CSS experience than actually learning CSS. It empowers teams of any size to prototype faster while compiling into maintainable source code. It even helps CSS professionals!If you enjoyed this article and want to learn more please visit Tailwinds website here!
Oldest comments (40)
Great article. Recently started using Tailwind, and I didn't realise about converting it into classes.
According to my experience, when you have 10 different types of border-radius is due to one of those things:
1- The designer / design team wants different border-radius for different contexts.
2- The boss wants different border-radius because its daughter says it looks prettier.
Then I would like to see how dy justify to your boss that you cannot add different border-radius.
The third reason could be not using coverage tests and having/being so bad developer that you need a tool that enforces you to do the things right.
By the way and to add more laughs into this comic situation you're already able to write a custom CSS Lint to ensure all the code looks the same with the same rules and if you use Sass and a simple bundler such Parcel it will blow off your repeated code and optimise it in the same "transpiling sass into css" process.
So i've to ask again because every day hundreds of frameworks, libs and other tech stuff comes around with crowds of students as companion shouting "This is the best!"
Remember before answering that IT is a science so there's no valid opinions here, there are facts. Maybe not at student level but at business level definitely yes.
So if your hopes about a tech cannot be converted to more efficiency (better economic margin for operations) they are not true.
Also we build products and there are many things to keep in mind that you've not (usually) in consideration when being a student or working on low-tier software only.
If you (or anyone) can answer that correctly with an overall PoV it would be a nice post that I would read consciously. Some of us have not enough time to try all the stuff because the products we're involved in are so big that we've to waste time trying architecture concepts, evolution, tech refresh planning and so (but when I can, I do that and I try to post the results for the community) and that's the good thing of the IT world... you can be involved in something and get pieces of experience from other's.
You seem to not to know the existence of tailwind-config which is a file where you can customise absolutely every aspect of tailwind.
Thanks for your detailed answer, i'll need to read the entire doc, not "more about" to be honest, I'll take a look after the current certificates i'm hands on.
Just to mention the point of having a tool for each job is that (in this example) you don't only compile and optimise CSS, you can deal with JS as well on the same bundler build which you'll need to do apart if you use a stand-alone tool for CSS so you'll end up with same number of tools anyway.
Apart from that, adding a bigger tech stack on a project means you'll need to find devs who know the entire stack or otherwise taught them. The first thing is near impossible this days due to the big fragmentation and the second one is an extra cost to the project.
You'll need to sum the tech refresh cost (to avoid or surpass the tech debt). Let me tell you a quick story... back those days jQuery was a must, a breaking change, then jQuery UI appeared and woah! (it was some nice try to reach what nowadays we know as react, angular, svelte etc) Nowadays all those projects made with jQuery and specially jQuery UI are involved in a tech refresh to quit using that and the target is JS ES6 and React or Angular or... respectively.
You know what do need a refactor from time to time but keeps a much extended life cycle? "Standard"
I put it in quotes because in web dev world it's a unicorn word but the standards are here to take and if you rely on them instead using custom tech you'll end up saving money most of time.
If you ask me for the tech stack for a 100M software product I would probably pick React due to its benefits but I'll be more picky with a "tool for styling" and more if you talk about "custom CSS properties".
To end this comment I've just searched "Tailwind" on LinkedIn jobs and I've found only three job offers that mention Tailwind and the format is that one that follows:
Take you own conclusions about that, and if it's a good tool (i'll test it by July approx) I hope it'll grow up but i've seen many good tech that is not popular enough like webassembly stay in the background sadly. The time will tell.
Edit: Oh I just remember about CSS Houdini, wasn't that supposed to do something similar to what tailwind does? It was also acclaimed by many people but if I follow my feed it's dead since time ago
"LinkedIn is not a real source of truth anymore" ahá ahá so you'll highlight newspaper ads searching for developers or what?
I'm in touch with loads of IT professionals I've known all those years and know what? All of them had been employed from LinkedIn once or multiple times.
Last time I wanted to switch I went to LinkedIn jobs and "et voilà".
If the platform that matches more IT recruiters with IT professionals in the entire world is not a real source of truth tell me what could be.
I have been working as a developer for about 12 years and none of my jobs/projects have been found via LinkedIn.
Stack Overflow jobs is a much better source of truth that LinkedIn, which IMHO is a little bit of a wasteland.
No doubt tailwind is powerful in its own way, but I'm a little confused as to what the point of this example is. Your end result looks practically identical to the Bootstrap equivalent, but requires extra work and a compilation step to get there. If one wanted the "so much cleaner" semantic CSS classes that you end up with in this example, why wouldn't they just use Bootstrap instead and cut out a few steps?
You can use Bootstrap in anything you like. But with Bootstrap you need to dig through the file and update many locations to make small changes in its source. In terms of rapid prototyping this can be counter productive. This being said I do believe there are tools which aim to make this a little simpler. Such as this. But for the most part you still have to dig in and make many changes to components to style them to your requirements. The point of this article was to help people know about the extra compile step which enables developers who prefer semantic classes to also enjoy the framework. There are many objections to utility frameworks due to the ugliness they leave behind within the project files. And I was aiming to shed a little light on this feature.
Interesting perspective. Maybe I just have a different workflow. I've been using Bootstrap off and on since it was called Twitter Bootstrap, and I've never once needed to dig through the Bootstrap source and make changes. As a matter of fact, that sounds counter-productive, as updating Bootstrap when new versions are released would simply overwrite your updates. So I don't quite understand the scenario you're describing. All I see with Tailwind is extra work to get where I want to get to.
So Tailwind just does everything I can already do with CSS (obviously) but I have to add an extra dependency and build step; learn its way of defining established CSS rules; and add more technical debt to my project?
Your article is well written, but it does nothing to convince me that Tailwind is worth the effort. Surely, given all the hype, there must be more to it than that? For example, I know there's some configuration available: does that bring something that I can't easily achieve with CSS? E.g. could it facilitate theming?
Well, you get tree-shaken CSS with minimal redundancy... I have to see those results when the CSS is written manually.
OK - so there are tangible benefits beyond duplicating standard CSS functionality? That's what I want to read about! Preferably with some comparisons with the CSS and pre-processor equivalents; so I can weigh up the cost/benefit of including Tailwind.
I've seen too many "Tailwind is amazing" articles (this one included) that just present the basic functionality as if this is enough justification to make the switch (IMO it isn't!); so my comment was a genuine invitation to provide some more concrete justification for all the hype 😅
So thanks for the comment: that at least tells me I should look into the docs in more detail to see what else it brings to the table.
you can build a coverage test with puppeteer in less than 10min which will ensure you don't have unused or repeated code inside not only your CSS but your JS too so I would say good practices and tests are a must while Tailwind is not
You are complaining about an extra step and you want to set puppeteer up. Come on!
It is not about repeated code though, it is about redundant code.
You'll need to add tests anyway so it's a win-win.
I'll try - as I said - Tailwind by July (i'm busy enough till that) and maybe the situation turns out that tailwind ends up like CSS Houdini did so I can avoid to learn a dead thing or maybe not and it's really good and a breaking change, will see, the thing i dislike more about what I've been reading about is this "custom CSS properties" tbh
You don't test CSS, you test the visual results of the CSS.
Custom CSS directives is basically any modern CSS preprocessor, like SASS or LESS. Not sure what is your point anymore.
well I feel like tailwind is late. With Sass you can code styles on a much more reasonable way (better by means ease to maintenance and refactors/reworks) so I can't find a reason to use a different tool than mainly CSS / Sass
I haven't used the library yet, but it does look like it's worth it. It comes with support for responsive design and dark mode (which i guess answers your doubts), and being able to extract tailwind classes to custom CSS classes using
@applyand it having IDE autocomplete support as well just makes it a more attractive option for me.Seems like using it with a front-end library like React or Vue would be an intuitive experience, and doing so would also mean you can implement theming for your application.
Your sample probably misses the point of tailwind. One could just have written raw CSS here, without all the compilation fuss. Thats what I first tought about tailwind. "This is just glorified inline css"!
I think the main idea is that:
tailwinds primitives are a bit more constrained than raw CSS. For instance you agree to a grid (15px ex) or to a color scheme;
Modifiers are cool. And you can create your own (ex: sm:xxx)
the major value lives in the power of the settings
the main downside is that you need a somewhat complex build process, even a custom editor plugin, just for adding glorified inline CSS?
I don't understand all this criticism with "very complicated build process" when it is really easy to set up.
Of course adding a dependency to your project is just a trivial
npm install --save-devaway (and hopefully minimal config); but what you're also adding is technical debt. So the question is: does Tailwind provide enough functionality (compared to well established solutions) to justify this? Is the config - to use it effectively - minimal in practice? How easy will it be to replace when the next new and shiny CSS solution comes along? Will new developers (who should already know CSS) be able to pick it up quickly? How maintainable is the code going to be? etc. etc.There's far more to properly managing a project than installing the latest shiny toy because everyone's raving about it...
How it adds technical debt?
What adds technical debt is to have a trillion lines of redundant CSS. Adding a library does not add technical debt.
Depends on your definition I suppose... but IMO adding a library absolutely does add to technical debt; especially if not well managed. TBH I can't be bothered getting into a long discussion on that subject right now; so I guess we can agree to disagree on that.
Anyway - the point is that some developers are more cautious than others; so we want to see tangible, quantifiable benefits before investing ourselves into a new library. As far as Tailwind is concerned I'm yet to be convinced 🤷
I am with David in this regard. Libraries don't add technical dept per se.
Technical debts are nothing else than poor code quality and poor architectural decisions. It is just a nicer way to tell the customer that the code base became a bit messy and some stuff needs to be refactored.
Not a problem on a new project. But definitely not the most transparent build.
Do the other CSS frameworks require a build step? Imagine if every JS framework required an additional babel plugin. Adding extra webpack plugin IS complicated, compared to adding an HTML tag.
In the computing world, "everything can be solved with an extra layer of abstraction". Tailwind do this nice, but in vanilla css you can do that too. For me, Tailwind is like a "jquery" of css.
In the real world, we use frameworks not because things can't be done from scratch, but because we don't have all the time in the world to do things.
Indeed. To be fast and write less with Tailwind, you need to add another layers of abstraction. It's the almost same work and time we spend creating classes in vanilla css. That's my point here, and not "doing things from scratch".
Yup discipline is all.
I feel that recommending
@applydirectives for building all the styles is missing much of the point of Tailwind. Aside from constraining you to a theme to enforce consistency, that approach offers little advantage over vanilla CSS.Where Tailwind shines is allowing for simple maintenance of styles self-contained within a component, without the need to hunt for it within a separate CSS file. Additionally, using the utility classes helps avoid unintended cascade or specificity issues.
I use
@applysparingly in my projects, reserving it primarily for styles frequently repeated in different places across the project, like a button. For something like a card in this post's example, I would almost always create a Card component and use Tailwind classes to style it.I wrote this article quickly without diving too deep into the framework in my explanations. Maybe I will write a more detailed article that gives more information and directly compares it to another workflow. Ultimately any developer should compare the framework to their project needs to determine if it is the right fit for them. I failed to include this in my article.
I believe Tailwind is an incredibly useful tool to any developer given the chance. But I think it really shines with newer developers or developers with little exposure to front-end development. The tooling included with Tailwind such as the building, tree-shaking, and such are incredibly useful. But each feature likely requires its own article to really demonstrate the tangible benefits. I wrote this to be more of a brief overview of the framework for those maybe on the fence about giving it a shot.
Please comment to this with anything specific you would like to know about Tailwind and I will dig into it possibly with another article. Ultimately I want to help give information that helps developers understand more and gives them insight.
I would say that people criticises Tailwind because some guru does not like it. It is not a silver bullet, by any means, it has its pros and cons, but most of the criticism I see is just parroting other's opinions, and many times those don't even fully understand the thing because they have never really used it.
There's not much you can do against that.
It's definitely worth learning, if you want to use it afterwards is up to you.
that is blatantly false, as the usage is growing and growing, right now more than 800K weekly downloads on NPM. You probably don't know what are you talking about though, as it uses classes, not inline styles.
There is no such thing as "inline classes".
tailwind is an over engineered shinny framework