Tailwind vs. Semantic CSS

Writing and maintaining clear concise CSS for a large application requires serious effort. It usually fails fast as the design grows and changes and a larger team tries to work on the codebase.

This falls down to the old "it depends" slogan. Tailwind is a great way to scale a your css with a larger codebase / team while semantic CSS will give you a smaller tighter stylesheet and cleaner html for that single handcoded landingpage or blog.

Also the download cost of tailwind falls as the size of the app grows and each utilityclass is used in more contexts.

Bear in mind that the Tailwind example is the official template made by the Tailwind developers themselves. It is the prime example of Tailwind and it's benefits and best practises. (Should be at least)

it's just CSS yes, with the focus on naming your classes depending on the content you style instead of their looks. "article-excerpt" instead of "bg-white padding-2 shadow rounded".

I strongly doubt a reasonably designed "semantic" design can be half-forgotten after taking a break; the fine points of the implementation of sophisticated rules (e.g. why did we put the left border on the parent and the right border on the child) might suffer from obsolescence and lack of documentation, but the markup structure and the names should be obvious.

Forgetting what plethora of non-semantic classes should be used on what elements seems a far more likely problem.

This article makes some bold, false claims. What is true is that Tailwind will generally result in a bigger stylesheet over the wire than if you hand-write CSS. That's a well understood trade-off, made in exchange for several benefits.

But then the article suggests that every claimed benefit of Tailwind actually doesn't exist, and that Tailwind is in fact worse on all fronts. He seems genuinely to believe that there is no merit in Tailwind's huge success at all, that it must entirely be explained as arbitrary flocking behaviour. What idiots we must be, going to all this effort to write bulkier CSS, more slowly, with less flexibility! I have to guess that the author has not given it a fair trial (i.e. using it on a real project in earnest) before coming to his conclusions, nor had any good conversations with old-timer CSS experts who love CSS and love Tailwind. He's jumped to the conclusion it's a thing noobs like because they find CSS too hard.

I made a similar assumption at first, that Tailwind was just another horrible "CSS-in-JS" type thing, which I always felt were for front-end newbies who were so reluctant to just learn how CSS works that they'd be seduced by shiny packaging and use horrible JS contortions to 'shield' themselves from inheritence and cascading (which are actually useful, powerful aspects of CSS when understood).

But then I started to notice its hype cycle felt different, that even a few old school traditionalists seemed hooked on it, and I tried it out in earnest on a project. And I soon realised it's a very rare thing: a real innovation in front end, the kind that comes along every 5-10 years, up there with the component paradigm. It's not another CSS-in-JS thing at all. With Tailwind, you are writing CSS, in a very real sense. And thus your success with it is highly correlated by how well you can write CSS by hand – it is not an alternative to learning CSS; it is an extra, more advanced thing you should learn after learning how to do handwritten CSS well. What it brings is a beautifully designed build layer that justifies its own existence better than any other build layer I have seen 20 years of front end development. It gives you a massive net reduction in 'indirection', letting you style things right where they are. And it reimagines style 'reusability' in a way that (to be as succinct as I can) prevents your styles ossifying your DOM structure too early during the creative styling process. These are some of the reasons why Tailwind has blazed through the industry the way it has. Not because we don't understand CSS and want to avoid it, but because we want to write more of it, quicker and more flexibily.