As I understand it, Tailwind is essentially CSS 2.0 - or 5.0 I guess - with the warts ironed out (sorry for the unpleasant mixed metaphor): A) CSS / Tailwind:

As I understand it, Tailwind is essentially CSS 2.0 - or 5.0 I guess - with the warts ironed out (sorry for the unpleasant mixed metaphor): A) CSS / Tailwind: lots of little 'atomic' classes describing individual visual properties. Easy to understand, easy to customize, but slow to read, slow to get started, with plenty of stuff to learn B) CSS frameworks / Tailwind-based components: fewer classes declaratively describing the component's role (eg 'btn-primary'). Quick to get started, elegant to read, but prone to abstraction leakage and trickier to bend to your own exact specifications There's always been a need for both kind of tools for different projects and there will always be, in the same way that e.g. network programming may involve anything from bit-banging commands to high-level protocols. (And you will often go back and forth in the same project: you quickly crap out your first draft using prebuilt components, then it turns into a serious project and you start actually investing time in design and twiddle with the individual properties, and eventually it grows to a large project where you now have to go back to components again for the sake of maintainability, but this time it's your own components with your own accumulated set of properties.) Over the years CSS frameworks kept improving, but CSS was much slower to do so - although it acquired flexbox, grid, etc., the language limitations stayed, and they were bad enough to e.g. spawn SASS/LESS out of a genuine need for better maintainability. Tailwind takes all the stuff that was added to CSS over two decades, like media queries, and makes it part of the core nu-CSS language design. Tailwind saw a ton of hype and adoption because all the developers who had always wanted to go the (A) road now had a well-designed set of simple classes they could use with a lot less hassle, plus a bunch of developers who had adopted (B) because it was the road that had all the momentum suddenly realized that they probably wanted to use (A) once it was made less painful. Many of the flame wars between "pro-Tailwind" and "anti-Tailwind" people were actually disagreement over whether to take the A or the B road. Using @apply, header classes, or component projects like DaisyUI somewhat resembles using a CSS framework like Bootstrap, but by building on top of Tailwind it means that, when your project or resources grow and you want to move from (B) to fully customizing your style in (A), you will be able to write your individual little graphic touches in Tailwind instead of plain CSS.