Criticisms of Tailwind Criticisms

Tailwind is great and we don't mind saying so but there are also real, entirely valid criticisms we thought we'd address here. As a company that uses Tailwind for both marketing and application design, we have some thoughts.

Criticism #1: "It's just like this weird extra (unnecessary) layer on CSS right?"

It's easy to just think of Tailwind as this gunky abstraction on top of good 'ol pure CSS, but Tailwind's utility classes encapsulate so many of the great parts of CSS in tiny little bite-sized pieces. And because they're composable, you can do things like put them in any order in your class attribute and have it render the same. When you combine this composability and the Tailwind community, you get a this great collection of frontend "recipes" for different components that you can mix, match, and modify to your heart's content. Though you can also share CSS snippets, because they're usually much more complex, and you have to take into account the location of the style rules in the CSS code, and whether or not any rules or selectors are being overwritten.

Criticism #2: "So now I have to learn some mini frontend DSL / frontend language?"

Tailwind is something you have to learn in addition to CSS, certainly, but it does such a good job of keeping CSS keywords (border-black) as well as adhering to its own internal consistency (p-1 for padding, m-1 for margin, etc) that it makes it quick to pick up. And of course, for anything you need to, you can always fall back to CSS.

Also, and this is incredibly important, Tailwind class names are semantic. Like border-black, they tell you what the class is actually doing (err, making the border color black). Reading a long list of Tailwind classes lets you piece together at least a rough understanding just from the source code. With something like bootstrap there will be a class like navbar where you have no idea what it looks like or what styles are being applied without reading the documentation.

Criticism #3: "It all looks the same"

Tailwind components are easy to borrow, which means it can be easy to see the same look cropping up on a number of sites if they're all cribbing off the same styles (we would never!), but the framework is actually fairly flexible - you can implement Material Design patterns and design completely in Tailwind, for example (Smelte does it alongs Svelte.js), along with a more Bootstrap-ey look, or whatever else you'd like. I think it's also fair to point out that Tailwind was principally conceived as a protyping framework. That means its sufficient to get something pleasantly minimalistic, with the thought being that as your app or project matures, it can be customized with a little extra flair. Besides, going all in on Material design seems to work for a number of apps.

Criticism #4: "Function (HTML) and design (CSS) should be separate. Tailwind mixes everything up"

There is a school of thought that Tailwind muddles up a proper separation of frontend concerns that dictates CSS and HTML should be distinct. Writing a bunch of HTML classes is like "coding in the nineties" again, with the jumble of markup all collapsing into one big heap.

I think it's a valid criticism, but depends on the kind of separation you actually want. Tailwind is great combined with component-based, composable Javascript libraries like React and Vue, or more batteries-included frameworks like Angular. When you have an individual component, let's say rendered in React, you no longer have to include a seperate stylesheet that may or may not be scoped / component specific. With Tailwind you keep everything in the markup (in this case JSX), with JS, HTML, and CSS reduced to just props, tags, and attributes. In this case the principal separation is between components, not languages.

Criticism #5" "You don't need it!"

You could just use your own stable of utility classes, where you define what global SCSS text colors, layouts, etc, you want to use, but that means you need to take the CSS style rules' location into account, scoping, and a bunch of other small decisions that Tailwind (blessedly) takes away from you. One of its draws as a prototyping framework is it puts some of this stuff on rails and lets you iterate on your designs much quicker.

This list is by no means complete, but covers some of the biggest gripes about Tailwind and hopefully shows that, while some criticisms are understandable, it really is - taken as a whole - a crackerjack frontend design tool.

We couldn't live without it.