Hacker News Reader

Comment by boxed | Hacker News Reader

Projects with a single gigantic CSS file also work and you can onboard people etc. That's not an argument.

they do work… for any value of work. I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another preprocessor and starts splitting files, and then a whole new set of new, made-as-you-go conventions comes in: Files per component or per view? Or rather per architecture concern? Usually a mix of them. As files are split, the class naming gets even more inconsistent.

And at that point, onboarding a new developer always means wasted time on understanding this whole organically grown set of bespoke conventions, class names, patterns, hierarchies, and so on.

Tailwind does not really have this pattern of deterioration growing along both time and complexity, it stays consistent on both axes. So it's definitely an argument IMHO.

> I have been in the industry for a while

> Out of curiosity how long have you been doing frontend development?

I've been writing CSS since IE 6 and I can tell you not a lot of us oldies like tailwind. I've only seen a strong inclination towards Tailwind from the newer generation frontends (2015 and beyond)

Us oldies actually prefer BEM over anything else.

My talking point is based off internal comms from a large'ish company (200+ FE devs) so YMMV

Many of us oldies who started working on the web years before IE 6 actually like Tailwind. We all have our preferences. But I know multiple 50+ year olds who have been doing this work since CSS was barely a proposal who now use Tailwind.

Hah, yeah, there's always anecdotes. I stopped doing frontend a decade or more ago (and even then it had been a smaller and smaller part of my day). But I see the appeal of it. I started front end when we had to buy testing desktops that were beefier so they could run multiple VMware VMs, one with IE3, 4, 5, 5.5.

I remember the delight that our designers had when Javascript came out and my buddy showed that you could do some magic on images and form elements and have an actual checkbox with a check in it, not just a filled or empty box or circle. Or of the dev who thought he'd impress a girl on IRC by updating a prominent site's homepage to have a "Hi Sara" underneath the banner because he could just ftp to prod from his desktop.

Tailwind trades cascade complexity for design drift when working across teams. You can’t ignore that it encourages a different kind of undisciplined sloppiness.

Would I take it over the 1000 line cascade problems? Probably, but I’d still prefer css modules over tailwind.

What kind of design drift do you mean? You set `--color-surface` in your theme once, then all surfaces in the app use the same color with `bg-surface`, regardless of the theme authoring parts of it. I don't know how you could enforce more consistency to CSS authors than Tailwind does.

What do you mean it trades cascade complexity? The cascade complexity in CSS itself, tailwind can't turn that off, you always have that.

Reply on news.ycombinator.com