A) There are some important differences. For instances: sizes, spacings and colors are picked from a scale, not set in pixel values (although you can do that no

A) There are some important differences. For instances: sizes, spacings and colors are picked from a scale, not set in pixel values (although you can do that now if you need it.) B) There are many ways to "reinvent inline styles", this one is good, actually. I used to work with a fairly mature codebase. We enforced BEM-style names, but otherwise the CSS was extremely ad hoc (which, it is my impression, is quite normal). I ran some queries on our existing code, and found that most of our CSS classes were only used once, and most elements had only one style. They quite often had generic names, though, and when working with them you were always afraid to change a class because you didn't know if it'd been recruited elsewhere. And you certainly didn't delete anything. The growth in the size of the CSS was also quite extreme - it doubled over a year as far as I can remember. Probably because nobody ever deleted a class, even when they stopped using it, because then you would've had to check for sure that it was now unused and.. meh. I starting referring to all this as "might as well be inline"-styles, because really, all we did was move the inline information to a different file, which... has no benefits when you think about it[0]. A thoughtful application of atomic CSS would have been a massive ergonomic improvement IMO, and I've since used Tailwind on a big project and found it much, much easier to work with over time than the other system. [0] Yes, I know about the CSS Zen Garden. I don't think the principles apply to web applications - and, if anything, the approach to colors and font sizes in Tailwind makes theming much easier than in a messy codebase like what I used to work with.