I used plain CSS for more than a decade and felt the benefits of Tailwind within 10 minutes of getting started. What fueled the growth of Tailwind is that it makes web development palpably easier.
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
Erm. Isn't this one of tailwind's selling points? That you have a set of classes that you keep reusing?
Compare tailwind classes to bootstrap classes and you'll see what I mean.
CSS Modules are a JS-only third party solution re-invented/re-implemented in a dozen different ways for various JS frontend frameworks. Requires setting up, requires learning an additional library.
If you mean these CSS modules: https://github.com/css-modules/css-modules?tab=readme-ov-fil... then they need to be supported by whatever build chain you use. And you literally need to use them slightly different than normal CSS. E.g. for Vite yuo need to have `.module.css` extension. And they often rely on additional libraries to learn. E.g. you can enable Lightning CSS with aforementioned Vite which comes with its own CSS flavour: https://lightningcss.dev/css-modules.html
If you mean CSS import attributes, they only appeared in 2024 in Chrome and Firefox, early 2025 in mobile Android etc. and they don't provide magical local scoping out of the box: https://caniuse.com/wf-css-modules
This is what OP was talking about:
https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Nest...
I still don't understand what layering is, and why you would use it.
But, given that one would need build tools for tailwind as well, the requirement for build tools couldn't have played a role in the choice between the two.
When working with a component-based UI (like in React), the components are typically the unit of reuse. Those CSS classes are used in one place: the component they're defined for. It's annoying to have to come up with a name for them, and to have to work in a separate file, especially if I just want `padding-inline: 4px` or `display: flex`.
Some argue separation of concerns, but CSS is inherently tightly coupled to the structure of your HTML: there's no getting around that. `.foo > ul` breaks if you replace that `ul` child with an `ol`.
I do agree that more intricate styling is harder to read with Tailwind, and I have some other gripes, too, but in general it's a good trade-off for component-based UIs.
I mean, Tailwind is not that different here - you must use a build tool to tree shake the styles, etc.
There’s already a style attribute on every html element that does exactly that, and works fine in components.
“There must be something more…?” But it turns out there’s not. Just shorthand class names to save you having to type padding-left:4px
> on large screens
> in dark mode
> when hovering
> bg should be red-500
The above is an unrealistic example, but, you can't achieve that with the style attribute. You'd have to go into your stylesheet and put this inside the @media query for the right screen size + dark mode, with :hover, etc.
And you'd still need to have a class on the element (how else are you going to target that element)?
And then 6 months later you get a ticket to change it to blue instead. You open up the HTML, you look at the class of the element to remind yourself of what it's called, then you go to the CSS looking for that class, and then you make the change. Did you affect any other elements? Was that class unique? Do you know or do you just hope? Eh just add a new rule at the bottom of the file with !important and raise a PR, you've got other tickets to work on. I've seen that done countless times working in teams over the past 20 years - over a long enough timeline stylesheets all tend to end up a mess of overrides like that.
If you just work on your own, that's certainly a different discussion. I'd say Tailwind is still useful, but Tailwind's value really goes up the bigger the team you're working with. You do away with all those !important's and all those random class names and class naming style guide discussions.
I used to look at Tailwind and think "ew we were supposed to do CSS separate from HTML why are we just throwing styles back in the HTML". Then I was forced to use it, and I understood why people liked it. It just makes everything easier.
And I was super skeptical about it at first. I almost said no to it, but I trusted our main ui guy and wanted to allow him autonomy. And I ended up loving tailwind after working with it.
For creativity, I wished I had the time to get really good with css. It really seems to have grown a lot. Using sveltekit, its really easy to get component scoped css
There are plenty of other problems Tailwind solves, but these two alone make me never want to go back.
Besides, there recently have been several crucial improvements to CSS to address these pain points. One is CSS layers, which lets define custom layers of specificity that help with the discipline (e.g. resets or some baseline styles go in a low layer, component styles go in a higher layer, and finally overrides end up in the highest layer). The other is CSS scope, which prevents the leakage of the styles. These should greatly help with the specificity issues; and @layer is now sufficiently broadly supported that it is safe to use.
> If you’re writing markup for a component, you have to jump between two files.
Yeah; one of the reasons for my question about the groups in which tailwind saw the biggest growth was that in some ecosystems jumping between files was not a problem to begin with. Vue, for instance, had single-file components, where css could be written in the same file as javascript. So did svelte. So does astro.
As someone who writes tiny amounts of CSS these days (having known it reasonably in the late 90s and early 2000s with all the hacks and IE related bullshit), I have _zero_ interest in it.
If I'm doing it, it's only because there's no serious cross-platform equivalent to Windows Forms to power small experiments, and curiosity is certainly not there to improve the experience.
We can agree to disagree about that, and that’s OK.
I should note that other than Clojure, I absolutely hate dynamically typed languages. I suspect (though dunno how to prove it) that folks who like Tailwind probably like statically typed systems and maybe functional programming- it seems to fit into that philosophical niche. And probably people who like vanilla CSS are in a different category.
I’d love to hear from both camps to find out whether or not that tracks.
I love vanilla CSS, love typescript, have a huge respect for functional programming, but also don't mind OOP ¯\_(ツ)_/¯
What if you need to copy a element with tailwind, this later gets altered to include a slightly different style, but wait, now you have a original somewhere else in your code base, that is missing those updates. So you require the discipline just like CSS to keep things up to date.
Tailwind is great if you use it sporadically ... but have you looked at the source code of so many websites that use tailwind? Often their entire html file is a horrible mess million miles long tags.
I am amazed how often people do not even realizes that CSS supports nested Selectors? With nested Selectors, you get the benefit of creating actual component level structures, that can be isolated and shareable. Yet almost nobody uses them. I noticed that most people lack a lot of CSS knowledge, and they find it hard because they never stepped beyond the basics. Nor do they keep up to date.
You solve these problems by creating abstractions in JavaScript (most likely react components), exactly the same way you'd solve any other sort of code duplication.
By using tailwind (or inline styles), you go from two system of abstraction (CSS, JavaScript) to one (just JavaScript).