One thing that has always struck me about Tailwind is that practically every argument its proponents use more or less boils down to “I never learnt CSS beyond a junior level” . It’s super common to hear Tailwind advocates say things like “Without Tailwind, we would just have one big disorganised CSS file that always grows uncontrollably and ends up with loads of obsolete stuff in it and !important everywhere! Tailwin…
It's worse than that; the common arguments for Tailwind literally derive from total ignorance of how CSS is made to work, and a disposal of guidelines that developers would worship in any other context (i.e. Don't Repeat Yourself). It's really frustrating to be talking with someone about Tailwind and CSS, and realize that not only do they not know what "cascading" means, they never even considered the concept might b…
Moving away from Tailwind, and learning to structure my CSS
331–340 of 435 posts
Re: Moving away from Tailwind, and learning to structure my CSS
#332Re: Moving away from Tailwind, and learning to structure my CSS
#333Re: Moving away from Tailwind, and learning to structure my CSS
#334Re: Moving away from Tailwind, and learning to structure my CSS
#335I like tailwind because it lets you spend more time on things that matter and not bike shedding styles , it just doesn’t matter, zoom out more.
Re: Moving away from Tailwind, and learning to structure my CSS
#336Re: Moving away from Tailwind, and learning to structure my CSS
#337Earlier quoted context omitted.
With Tailwind: With style: Now more interestingly, Tailwind with hover and focus styles: That’s not possible with the style attribute. Even more interesting with Tailwind, a div with dark mode and responsive styles: That’s not possible either with the style attribute. Now your first instinct might be to "that’s unreadable", but keep in mind HOW you actually read and write this code. You’re not actually reading it to…
> Now your first instinct might be to "that’s unreadable", but keep in mind HOW you actually read and write this code. You’re not actually reading it to understand what it does like you do with iterative code. You see how the browser renders it, and you just adapt the code. Tailwind code is mostly write-only and maintained by viewing what the component looks like. This code doesn’t need to be reusable either, the who…
You’re still not getting it. That’s NOT what Tailwind is, because Tailwind works in a design system way, so when you use text-sm or bg-sky-400, you’re using variables that can be configured to suit your needs and keep a consistent design everywhere. Tailwind defaults and configurability played a huge part in its success.
Re: Moving away from Tailwind, and learning to structure my CSS
#338Earlier quoted context omitted.
It's unfortunate Inverted Triangle CSS (ITCSS) isn't more popular. Instead of resisting the cascade, it embraces it and makes it work for the developer. The summary: write your CSS in specificity order [1]: /scss/ ├── 1-settings. ITCSS basically does away with specificity wars in a CSS codebase. Usually the only place !important is the utility layer. [1]: https://matthiasott.com/notes/how-i-structure-my-css
Aren't Cascade Layers [1] a more reliable, native solution to the specificity problem? In 2026, why not lean on them instead of source order? [1] https://developer.mozilla.org/en-US/docs/Learn_web_developme...
They're admittedly less useful if you're already using component-based design. That's closer to something like BEM in hyper-targeting each element.
Re: Moving away from Tailwind, and learning to structure my CSS
#339Thats why I maintain the successor to tachyons: https://tachyonsneo.com No build pipeline. Resort to CSS when utilites make no sense. No lock in.
Can you clarify how this relates to Tachyons - do all Tachyons features work? Or is it a subset of Tachyons?
Building an application you use this as your utility layer that gets you 80% and for the rest you use an application specific custom css to write the parts where css is the best.
Re: Moving away from Tailwind, and learning to structure my CSS
#340Earlier quoted context omitted.
> This is what CSS classes were made for. That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hu…
> And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely. The client still has to decompress it and waste processing power parsing all the repeated text.