Tailwind CSS marketing and misinformation engine

One thing I would like to see is a re-implementation of the button in your style of CSS to strengthen your position. I'm not siding with either approach, I just think it would make the article better.

Your, "don't make things cleaner"/"make clean things", images show part of the Tailwind classes used to make the black button on one side and the class "primary" on the other. Elsewhere in the article you define "primary" as only setting the text color to white.

I believe the specific example is a strawperson argument - you're asserting that semantic CSS (as you've defined in the article) is better than Tailwind's approach. However, you don't show an alternative.

---

On a personal note, I've never seen custom (S)CSS written in a maintainable way in my ~decade writing it professionally.

Encapsulating styles by colocating them with the markup (Button.jsx and button.css, styled-components, Tailwind, etc) is the most maintainable way.

I think Tailwind works really well because it eliminates collisions at the global level and makes it really easy to see what a piece of markup will look like without having to change contexts.

As a fan of Tailwind's approach, I like to hear the other side.

Like many I was initially skeptical of Tailwind because I thought it made the code look “ugly”. But then I started using and almost immediately noticed the productivity boost. Two things that I noticed while using it was 1) I never knew how much I disliked naming things before I didn’t need to do that anymore and 2) how big of a mental burden it was to keep the mapping between the id/classes and the CSS, not mentioning the whole cascading part where you could never actually be sure just from glancing at the code what will be the resulting css. That second point is probably the most understated feature of Tailwind - you never have to wonder about the styling of an element again, because everything is right there in the classnames. The added benefit is that it basically forces you to write your UI code using components to prevent repetition - it encourages the best practice (note that this is where I think the OP went wrong when they asked “How to clean things up?” - the “@apply” keyword exists but it’s not meant to be overused as a replacement to proper code refactoring).

It’s not without its flaws - you have to learn a new syntax (which is in most cases very intoitive, e.g. “align-items: center” becomes “items-center”, “margin: 0” becomes “m-0” etc.) and it has its gotchas (for example it generates the css at build time by scanning your code and extracting classes you use to prevent generating unused css, which makes it impossible to construct a classname dynamically e.g. `gap-${value}`) but I take these issues over having to write CSS in any other way.

One point where I 100% do agree with the author though - you should first learn CSS before learning Tailwind. Not only because Tailwind could go away some day, but because this will give you a deeper understanding how and why stuff works.

The key point in this article is not Tailwind.

It is the endless susceptibility by software developers to marketing campaigns.

There are real costs to the use of any tool and these are completely glossed over by someone looking to sell you goods or services.

Here are some very real costs: technical attrition, maintenance, and training.

Technical attrition: Perhaps some people would use the terms amortization or depreciation, but I consider software to be in a separate class than intangible or tangible assets, the point being, there is a rather short shelf life for almost any technical product. CSS isn't going anywhere but tools like Bootstrap will come and go.

Maintenance: The old version of a CSS wrapper will stop receiving support and require upgrading to the new version which will take significant time and effort.

Training: There are orders of magnitude more individuals that know CSS than know Tailwind and they will be less productive for a given period of time.

For me, Tailwind is great because it actually popularized utility classes. Sure, there were others that did it first, but the approach as a whole is widely accepted and seen as a productivity boost. I remember when this was thought of as a really bad idea when it's clearly not. Now I think I have written more CSS than a majority of the population[1], and for me, the most productive workflow is the following:

- Semantic class names for components like buttons, sidebars, etc.

- A wide range of utility classes to fill in the rest.

Utility classes (in my opinion) are absolutely the best way to handle different types of layouts, positioning, and spacing. Especially when it comes to overriding the component level ones from the semantic class names. This is not a novel approach by any means, I mean Bootstrap does it and it's still great.

[1] https://www.gethalfmoon.com

Being a designer who does his work inside code, Tailwind is a nightmare. I hand off my design files, the developers do their thing. But then, maybe I want to tweak things after a review, or the design system changes, so I have to do a sweeping change to those buttons. Now I need to touch dozens of jsx/tsx files around the platform and make humongous pull requests, and the result is often dozens of merge conflicts. If I only touched CSS/SASS files, there might not even always be a need to have the files reviewed.

Another problem is readability. When things aren’t getting named, the files are often unreadable at first glance. And that’s what they are to external services like Pendo, which rely on classes to tie their thing into the UI. Which are now susceptible to change on a very regular basis, because when you change Tailwind styles “that only changes that particular instance”, or so the story goes.

Option 1: Find a visual error, open devtools, find the nearest most descriptive class or id (.primary? Oh no…), open IDE, global search in styles folder structure (most likely but not the only place to find CSS) for “.primary”. 40 files returned. After 15 minutes find a file that looks like it might be the right one. 10 minutes to understand the CSS (lots of advanced CSS in here…). Find the cause of the visual error, make the 1 line change. 30 minutes - job done.

Option 2: Find a visual error, open e.g. React Devtools, find the component name, open the IDE, find the component source file, find the HTML, change the utility style class, job done - 5 minutes.

These are not contrived examples. I had a one liner take 40 minutes to find in a codebase a couple of weeks ago. Not an exaggeration.

I really used to believe in separation of concerns but I don’t any more, because of all the time I’ve had to spend fighting with “option 1” codebases over the years. Pretty much any big codebase with normal CSS is going to be an “option 1” eventually unless it’s the work of a single good CSS developer (rare skill), or a team where someone who’s a good leader also cares about CSS enough to enforce a convention like BEM in perpetuity (even rarer skill).

Anyone building anything complex these days is using some component abstraction - whether it’s client side or not - to manage complexity. May as well make use of it for styles if it’s already there.

The reason that there’s a backlash against separation of concerns, the cascade, and (low) specificity is that each of these things is a complete disaster for maintainability in the long run.

One note in making an example of that Catalyst button. If you wrote out all the styles required to do the amount of work that button is doing it would also be extremely difficult to understand, and what’s more, it’d be in a completely different file to the single thing that gives it any meaning - the HTML.

I have no idea how tailwind has gotten so popular.

Tailwind is a way to justify writing inline css in our HTML. This was once considered the cardinal sin of a frontend developer. You avoided inline-css at all costs.

But now Tailwind just makes a class for text-color-blue which simply abstracts the `text-color: blue;` css property away into its own class. But don't fool yourself, you are just writing inline css by a different name.

There is no way to explain how it is more maintainable to write `class="rounded button hover:bg-color-black-700 bg-color-black-400 active:bg-color-black-500 focus:bg-color-black-500 rounded-sm text-sm text-color-gray-300"` instead of just `class="btn btn-primary"` using the "old-school" semantic approach. I can list numerous advantages of the semantic approach here. The only advantages of the tailwind approach is that you can style as you go and you can see the resulting style in the HTML page.

Tailwind fanboys will say "it's easier to style in the html". But that's not true. Tailwind to be done right needs a fairly complex set of tooling to enable the hot-reloading, minification, and parsing into your pipeline. None of this is necessary with simple CSS. Semantic CSS "just works" with no tooling whatsoever.

Then again, I'm old enough to have contributed to the famous CSS Zen Garden back in the day. So maybe I am just an old curmudgeon. But like all things, I expect that Tailwind's popularity will wane. Remember that before Tailwind, everything was Bootstrap. The point is that whatever tool lets developers be lazy and avoid learning fundamentals will be the tool that prevails.

The popularity of tailwind isn't because of their marketing. Many colleagues using tailwind don't even care or have heard about the claims in your article. It's popular because it solves a real world problem for small to medium sites. It challenges "best practices" by showing that those in fact are just very opinionated and don't solve real world problems for many sites. I've witnessed over 2 decades of css evolution and tailwind is by far the most elegant solution for developers just needing some style for their app that works.

I think that a huge part of Tailwind‘s success is not so much the underlying concept but a combination of several aspects: You get a kind of generic design system (margins, paddings, matching colors, etc.) that are restrictive enough to help make things look good and consistent but flexible enough to not result in a every-site-looks-the-same situation (at least not to the extent many other CSS frameworks did); Tailwind sits at a low level of abstraction above raw CSS that is just enough to make some CSS concepts a little bit easier to use (flex, grid, etc.); the documentation is quite good and getting started is relatively easy; …

Given these (and probably some more) aspects, Tailwind makes it easy to get some good results quickly which helps to convince users that their whole approach is the right way to go. Add very good marketing and early traction and you are where we are now.

So I agree with the article that Tailwind‘s conceptual approach is not the holy grail it‘s often said to be, but it maybe also is not even the reason for its success compared to many auxiliary things it did/does right.

> “optimizing for reusable CSS was going to be the right choice”

That is what CSS is. In the melee of “CSS in everything but CSS,” people might have forgotten what CSS is for. CSS’s classes are what you use everywhere again and again.

CSS Utility classes have been there for a long time and were made easy and famous by the likes of Bourbon[1]. They even have pre-defined styles — Neat[2].

Even though Tailwind can and should have been used more as what it was destined to do — utility classes. In a larger team, it is easier to stick to the TailwindCSS as such and have specialty/custom classes based on its utility for your project.

I was checking it out during its early release and introduced Tailwind to a team in 2018 who were stuck in Bootstrap. I wanted to stop hearing, “This is not part of Bootstrap.” The good thing I realized then was that if I followed a custom class with utility based on Tailwind, the result could continue to be the same with someone doing a “button button-blue button-large text-xl text-white.”

Btw, this too shall pass. I suggest learning CSS from first principles — everything that comes later will be another syntactic sugar. Remember, we started our projects with our grid layout that we stole from A List Apart’s faux-column layout, then came blueprint[3], bootstrap[4], foundation[5], bourbon, and now Tailwind, and every other one in between.

There was even a paid service (or a few, I think) that just churns out custom CSS grid layout code based on your drag-n-drop sliders.

1. https://www.bourbon.io

2. https://neat.bourbon.io

3. https://github.com/joshuaclayton/blueprint-css

4. https://getbootstrap.com

5. https://get.foundation

"At some point, hundreds of utilities later, the code you've written doesn't look pretty."

Personally I find diving through a bloat of identifiable tailwind classes allows me to review/change/adapt/create UI code MUCH QUICKER than having to re-learn some other abstraction or naming convention that some other developer came up with.

Complaining that lots of Tailwind classes "don't look pretty" makes me think the author has never worked on large projects/refactors using it.

To me Tailwind hits the perfect level of abstraction:

- not too low-level; allowing us to easily review/identify patterns in the code (p-0, leading-3, etc..)

- not too high-level; allowing us to not have to relearn a visual/naming pattern for every new project (.card, .button, etc..)

It boils down to being a search problem: how much of a language/DSL feature can I fit in my head? Reviewing a wall of CSS is harder for me to "search through". On the other hand a wall of Tailwind hits the right spot.

Tailwind is write only, you’re not supposed to read it or maintain in. Want to change some property? Delete the entire class=“” attribute and start anew. Take that primary button example from the article - no one is claiming that it’s readable, especially when there are hundreds of primary buttons throughout the app, each with a slight variation.

This works great for marketing or landing pages, or other use cases where it’s not you who maintains it after deployment; the next sucker will want to rewrite it all anyway.

Author here: This is probably the most important content piece I've ever written. Curious to hear your thoughts. Thank you!

> At some point, hundreds of utilities later, the code you've written doesn't look pretty. You start wondering what comes next after the utility-first step. How to clean things up?

> Turns out there is no next step. Or it kind of exists, but it's called "premature abstraction". You can start extracting classes with @apply, but the documentation for reusing styles [link] describes it as a bad practice.

> But what should I use @apply for if not for cleaning up? The documentation does not say. It only tells me why it should not be used.

If you jump to the Tailwind section they link to here, the short section immediately before explains with an example you should be using HTML templates to reuse styles over @apply, which is really core to understanding Tailwind:

https://tailwindcss.com/docs/reusing-styles#compared-to-css-...

  Unless a component is a single HTML element, the information needed to define it can’t be captured in CSS alone. For anything even remotely complex, the HTML structure is just as important as the CSS.

  Even if you create classes for the different elements in a component like this, you still have to duplicate the HTML every time you want to use this component. Sure you can update the font-size for every instance in a single place, but what if you need to turn the title into a link?

  Components and template partials solve this problem much better than CSS-only abstractions because a component can encapsulate the HTML and the styles. Changing the font-size for every instance is just as easy as it is with CSS, but now you can turn all of the titles into links in a single place too.

  When you create components and template partials like this, there’s no reason to use anything other than utility classes because you already have a single source of truth for the styles.

I agree with the overall sentiment of the article, but find it a bit harsh.

I honestly find the real debate to be inline styles vs stylesheets.

Tailwind is just fancy inline styles. Personally, every single time I've used stylesheets in a large production-grade project it's an absolute mess. Every project I start now I use inline styles. I'm pretty indifferent on Tailwind though, it's sometimes nice to get opinionated defaults.

The tech industry is full of thought leaders trying to sell us their inventions.

Adam should have said that Tailwind is a good solution for him. Instead, he said that Tailwind is better than everything else and piggy-backed on famous people in tech to sell his idea. Which created a cult-like following.

Cults are bad for tech because it prevents out-of-the-box thinking.

I think Tailwind appeals to « back of the front end » devs which is a role that didn’t exist until 2010 or so?

I think tailwind is valuable and as always middle way is the best approach but more difficult to structure and definitely not good for commercial purposes.

My favourite way is to put tw classes for spacing components and layout directly in the template while using bem-like naming for the component ‘s own appearance.

Having utilities like mb-2 that can override the default set in a component I think solves many headaches and is one of the strengths of having a full set of utilities.

However I also find a real strength is having a standard accross devs AND projects and so when tailwind advises to customise your project. Change the meaning of mb-4 or text-lg then I find it completely undermines the value of having a standard utility set.

This article ignores the fact that people actually used it and actually realized the benefits cited.

Traditional way of using CSS I feel is still advantageous for websites (instead of apps) with a limited set of highly reused styles.

Nowadays however there’s a general lack of restraint and self-control when it comes to web design, you must have a million variations of everything.

In that case utility-first CSS clearly wins because there’s almost no reuse except at the per-property level.

I don't see the value in Tailwind. It gives you convenience but adds complexity, one more thing you have to learn and makes it easier to shoot yourself in the foot. Also, I like the no-bundling approach to application development with Web Components and Tailwind goes against that.

I prefer using plain CSS. I like semantic CSS and similar ideas of associating certain component class names with certain styles.

While I agree with the principle of "clean markup", whenever I open up the DOM of websites I did not create (and I do so with regular frequency), I generally do not see what I'd consider clean. The author is correct but it's not that frequent of a practice; I wish it were so. Care for our craft is an uncommon thing.

Honestly this just feels like someone looking for a fight. I was creating custom utility classes a decade ago—long before Tailwind. Bootstrap, Foundation and other css frameworks of the time did something similar.

Tailwind is nice because it’s fast and you have a good idea what you’re going to get while writing it. Nobody believes that it’s the pinnacle of performance or maintainability. Keep using Tailwind if you like it and it’s appropriate for your project or business.

I think tailwind went a bit too far, but in general it’s really hard to have a controllable amount of css on huge projects. The reason is that selectors are often too broad and it’s not possible to say in general whether a particular selector is being used or not.

Atomic classes really shine in this aspect, since it’s really just what you have in html and nothing more.

Another fantastic quality is the fact that you can really tweak things slightly in the html and skip inventing a modifier class just for this particular situation.

I think bootstrap css hits a really sweet spot there, since they have lots of reusable components, which are very easy to use and extend and a huge bunch of utility classes to accommodate for exceptions. I know that’s not an argument for spas, since you have components there, but for server side templates that’s the best

I believe there are two problems Tailwind tries to solve: styling and layout.

For laying out items it might be useful but for styling it is not (why would you create a separate component for each HTML element, like a button!?).

And I even don't get the styling example in the article.

Why would you use a 'primary' class on a button while the button type makes it primary?

If you style your submit button with `button[type=submit]` you are sure all submit buttons in your app look the same. There is no need to use classes. (I also never understood why it is common to add a 'table' class to a table.)

I think the main reason why most CSS files become such a mess is that style and layout are not separated.

Tailwind seems to just be the right level of abstraction, a bit like how its easier to do python than cpp. For most things, writing styles inline seems to be easiest, but doing that with css is like writing cpp but writing tailwind is more efficient. Further, tailwind ALSO gives the ability to write class names like @apply. So even if tailwind is deceptive and under the hood profits from vendor login, an abstraction at the level of tailwind seems necessary?

I don't know if I've ever encountered any technology that has more "even though you like using it, you shouldn't be" energy directed at it than Tailwind.

Tailwind didn't win because of marketing... it's marketing was no better or worse than the million other new products that show up in a developer's feeds every 22 hours.

Lots and lots of people like using it. That's the whole story.

I like Tailwind because it's easier to prototype & modularize design. The HTML can be copied from templates, other sites, & it more or less works. Carson Gross, creator of HTMX, wrote an article about Locality of Behavior, which I believe applies here.

https://htmx.org/essays/locality-of-behaviour/

I don't use HTMX as I would like a smaller JS bundle. I would also like an efficient CSS system of utility classes. I think Hypermedia libraries & CSS utility libraries can be improved. I'm also working on app systems to reuse code across domains...using a consistent domain language. A challenge is interoping my domain ontology with other domain ontologies. The class name interop is an area where Tailwind has found success. You can start with their prototypes or another developer's prototype with copy/paste. This is great for engineers/developers who are less inclined to spend enough time learning the art of perfecting design.

This can happen in semantic markup as well, however the bounded context of the example site is less likely to interop with your app...because the semantic markup is less bounded than utility classes.

Tailwind also has `purge` to remove unused CSS classes. Yes, `purge` is a build step & it requires the js/html content to evaluate. However, if you want to optimize the JS bundle size, you probably use a build step.

I find it fascinating how Tailwind divides opinion.

Meh, tailwind is the most maintainable and easy to understand way of doing style I've experienced (from solo to massive teams). Been doing this for around 13 years, so plenty of time to try a lot of flavors of styling.

I'm so glad I no longer have to wonder what primary means, let alone the other weird names people come up with for classes.

And if you don't want to see the classes, just write it out into a reusable component called PrimaryButton, if that floats your boat.

Tangent: I couldn't find an RSS feed for the blog?

Personally I fall into the camp of Tailwind is great (if you use it in a sensible way). TailwindUI and to more of an extend, Catalyst is awful. The fact they have the nerve to call it 'easy', 'usable', etc is laughable.

The snails pace updates on TailwindUI are bad enough, in the time it takes them to release one tiny ~20 line component you'll see half a dozen new and better UI frameworks pop up. But to add insult to injury their obssession with over the top React and Vue usage on the most basic of components just highlights how disconnected from the reality of web development they've become.

It's a CSS framework. I shouldn't be seeing Next, Nuxt, React, Vue or whatever 'hot thing of the week' they're gawping at.

Where tailwind on its own shines is inside a Laravel project with blade components. They are their own individual, reusable and extendable items. Wheather thats better or worse than css classes is up for debate however.

I guess you're missing the whole point of an entire market segment adopting utility CSS like tailwind or uno (and windi before that) for reasons. It wasn't an arbitrary decision and I very much doubt it was mostly decided because tailwind guys are good at marketing.

Semantic CSS class names are a failure because the context in which they are named is often a moving target. In the real world, a good name for something at point A in the timeline is not likely to hold up at point B for the majority of developers out there. It also relies on a persons capability to extract meaning from an arbitrary name and hope that their understanding of what that means lines up with the original developer's intention of what it means. And then that can fall apart if you are working with teams with different cultural perspectives and language proficiencies.

Utility CSS also lets you tie into an underlying design system that enforces consistency. You know someone doesn't know what they are talking about when they make the claims that tailwind is just inline styling because it isn't. Inline CSS styles are absolute. Utility CSS classes are tied into a design system that can be mutated and changed.

Honestly, your whole Nue project is written about in such a way as to be mildly insulting. Like I would never even consider using it regardless of whatever supposed superiority it may or may not possess because you kind of come across as a pretty unlikeable know it all. I don't know if that's true or not, but that's the impression I get reading the stuff you've written. This article is sort of another example of it. You literally tell people who use tailwind CSS to "learn CSS" and that we are taking part of a "trend". It's got the real dinosaur vibe get off my damn lawn vibe going for it. That's saying a lot because I'm pretty sure I'm older than you and I've been doing this as long, if not longer.

Well done.

Oof.

First off, it feels weird for the developer of NueJS to be throwing shade at other tools for "marketing and misinformation", given the number of articles I've seen extolling the virtues of NueJS as the silver bullet to solve all your problems.

Secondly, I think it would be useful for the author to reflect a bit on what Tailwind is doing that people find so useful. Obviously not everyone loves it (personally, I prefer writing CSS to Tailwind, just because it's a much clearer and expressive language), but it's clearly very popular, and the reason for that popularity is typically unlikely to be a conspiracy involving easy onboarding and lock-in.

I think understanding Tailwind on its own terms, with its own merits, is really valuable for understanding the state of CSS development right now, what works well, and what needs to improve. The author here seems to see Tailwind purely through the lens of being able to write CSS decorations: in Tailwind I might write `m-4`, but in CSS, I'd write |margin: 32px`, these are equivalent, so why create a whole extra tool just to do what we could already do?

To me, though, this is deeply missing the point of Tailwind. Tailwind isn't just a different way of writing CSS declarations, it's a way of tying those declarations to components. This is nothing new - it's the same concept as BEM, or CSS modules, or CSS-in-JS, or scoped CSS, amongst others. Essentially, when writing large projects with extensive CSS, most people run into maintainability issues, and most people seem to develop similar solutions: they tie styles to an already existing, more maintainable unit of code, namely the component.

I can go into the details of where these maintainability issues come from, and why components are such a nice solution, but if you've worked with large CSS projects, you probably already know that stuff, and if you haven't, I think BEM is a good place to start for understanding how to organise CSS, and why using the concept of individual components with sub-elements and different states is very helpful.

Understanding Tailwind on its own terms, then, we start to get answers to a number of the questions that the author asks. For example, they compare a JSX-style declaration `<Button plain>` to an equivalent with classes `<button class="plain">` and ask whether the difference is just syntax. Well, let's analyse it from a component perspective: with the former, I know where the `Button` component is defined and can analyse it with my editor's code navigation tools, and I know that `plain` is scoped purely to that button. I also can't accidentally use `plain` from a button to annotate a checkbox - plain here explicitly refers to the button's "plain" style and it will not get applied elsewhere.

The same can also 100% be true in CSS - like I say, I'm not a huge Tailwind fan, and I personally prefer CSS solutions where they make sense. But it probably wouldn't look like the author has written it, it would probably look more like this: `<button class="button button__plain">`. That said, this still can have issues - the `button` class is completely global, and woe betide you if you forget it exists and try and define another `button` class somewhere else (or important one from somewhere else).

These questions of scope are hard ones to solve, which is why Tailwind exists alongside so many other, similar solutions. And I can fully understand why someone may not like the Tailwind solution specifically - its DSL for defining decorations is idiosyncratic, particularly if you're already familiar with CSS. But this article doesn't contrast Tailwind with those other tools, instead it compares having a solution for these issues with just not having a solution at all, and then tries to tell you that ignoring the problem is the better plan. I think that's a very disingenuous argument (possibly even an example of marketing and misinformation?) that makes the whole article very difficult to take seriously.