Let's be honest, I was a bit dubious about Tailwind at first. I was slightly put off by the idea of not writing CSS anymore, and replacing it with terse classes. But mostly because drawbacks were never really discussed, and that's usually a red flag. No technology or paradigm is perfect, there's always a downside. Tailwind is no different!
I decided to give it a fair shake after seeing it used in front of me in a convincing manner. I used it a a small prototype, where I thought the quick iteration everyone raves about would help me be done with the prototype quicker. And therein lied my first surprise.
The learning curve is minimal
This is dependent on your editor, but vim offers intellisense completion and the framework website offers a powerful and quick search for its great documentation. Both of these allow you to dive in quickly, and keep being useful in the long run.
But that's not the end of Tailwind's strengths. I have since used it on personal projects and at work to great effect.
The good
Normalised values ensure consistency
Most designs call for consistent spacing/sizing, and having pre-determined values help tremendously in keeping the experience consistent. If you were writing CSS, chances are mistakes will happen at some stage, and some spacing will slip through the cracks and not use your CSS/Sass variables.
CSS creep can't happen
CSS is really easy to add, but a lot more complex to remove, because of the degree of separation between code and styles/layout. This means that websites tend to see the size of their CSS balloon over time. Since Tailwind uses a purging mechanism to ensure you only get the minimal subset of necessary CSS, you avoid the ballooning problem. Especially since removing a class attribute from a component will not affect the rest of your app, no matter what (This is also true with BEM, but BEM is only enforced by your own vigilance, CSS-in-JS and CSS modules do avoid that issue completely though).
Long classes are a good thing, actually
It's one of the things that kept me from trying it in the first place, but there is something nice about being able to see what a component does in terms of layout and style at a glance. The naming is indeed terse, but still explicit enough to be readable! The added benefit, if using jsx-like syntax, is that you effectively consolidated HTML/CSS/JS in a single location without the usual downsides. I said location, not file, because even templated frameworks do keep CSS separated inside the file.
Flexibility is there
Don't like the default colours, or need to map them to whatever colours the designer picked, or create new colours? It's a small change in the config. Not happy with the spacing? Same deal. Need a specific CSS attribute not handled? Can be added in the config. It's a lot more flexible than it looks. But you know what? I've never had to do more than a couple tweaks, the package is fairly complete.
A lot less things to name
Let's be honest for a minute, naming things is hard. When going for your traditional BEM naming convention, you need to name a lot of things. With Tailwind? You use the classes on offer, one less thing to worry about!
But like I said earlier, it can't be all roses.
The bad
A complete paradigm shift
Since things are so different from usual CSS methodologies, it makes it hard to integrate on an existing project without forcing you to check things in two places, and keep two ways of doing things in mind, which can make the cohabitation period somewhat painful.
Setup is slightly involved
Since Tailwind has to generate the right css file from your build, it's not plug-and-play. You really don't want to use the CDN version for any production environment, it's a whopping 1M of CSS right there, so you'll need to wrangle some configuration no matter what. The documentation does a good job of presenting you with most of the cases you may encounter, but if your stack is fairly complex, this will need a fair bit of messing around. PS: You'll almost certainly want to disable the preflight when introducing it to an old codebase.
The missing bits
Tailwind doesn’t support pseudo elements, it’s honestly a bit of a bummer. But I truly don't see a way to integrate those that wouldn't feel incredibly verbose or overly terse. Especially when pretty much all of Tailwind classes are only really impacting the component itself. I guess that's what @apply is for. 🤷♀️ It's also not super flexible in terms of grid layouts, but I have never needed more than what's on offer when implementing a designer's vision.
All in all, this paints a fairly good picture of Tailwind, but I tend to hold my opinions fairly loosely, which has probably helped tremendously getting behind the idea of atomic CSS and the Tailwind approach. It may not be for you or your team, but it's really one of those "you need to try it to form an opinion" kind of thing. If you have the bandwidth to try it, it comes highly recommended.
Top comments (0)