Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

331–340 of 435 posts

Re: Moving away from Tailwind, and learning to structure my CSS

#331
post #42

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…

I'm fine with just the "cascading styles" part of CSS. The thing is it's also sizing and placement of elements in the webpage. Sometimes that's easy, other times there are 10 different ways to accomplish something that all feel hacky.

Re: Moving away from Tailwind, and learning to structure my CSS

#333
post #73
post #34

Earlier quoted context omitted.

Why did Svelte affect your stance towards Tailwind?

Presumably because you just put the styles in the component.

Maybe Svelte does it much better, but there were tonnes of scope-css-to-react-component approaches before Tailwind too.

Re: Moving away from Tailwind, and learning to structure my CSS

#335
I’ll catch some flack for this but having done this for a considerable amount of time, I just feel like there are harder and more time deserving engineering problems than how to make a div grey…

I 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

#336
I used the same structure 20+ years ago in the heyday of the web, when I was starting as a dev. If you use tailwind, that's a sure sign you don't understand css. That's all. It's a signal of your incompetence. And at the same time it shows that the dev ecosystem has serious usability issues.

Re: Moving away from Tailwind, and learning to structure my CSS

#337
post #175

Earlier 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…

> keep painting each room a slightly different shade until it looks right

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

#338

Earlier 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...

Yep, they solve the same problem. I built my blog on Harry Roberts' ITCSS paradigm some ten years ago, and found it extremely easy to migrate to cascade layers. They're an underutilized solution to addressing growing specificity.

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

#339
post #50
post #29

Thats 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?

It's just a rebuilt drop-in replacement stylesheet compatible to the built version of tachhyons 4.12 but using css variables (so when you need to write custom css you can use its tokens) and it has support for grid plus a few more modern utilities.

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

#340
post #159
post #120

Earlier 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.

Additionally, I do not think, that copy pasting a CSS class name everywhere is a realistic sane use-case. Usually, one would render some template and that template lives only in one place in some file, not all over the codebase. If we go smaller than a template, to use jinja language, we have macros as reusable parts, also not having them all over the codebase. It rings like a gigantic strawman to me.
Post reply on HN