Hacker News Reader

Comment by phphphphp | Hacker News Reader

I’ve recently started working on 2 legacy codebases, one with tailwind and one with scss. The #1 problem — that has cost me multiple hours! — is inheritance, because how developers write CSS and how business people think about design are very different. I constantly find myself causing side effects when making any change to the css, it’s a headache.

I don’t think tailwind is perfect but coming into a well-established codebase I am so much happier to see tailwind. I can’t think of a single issue I’ve encountered with tailwind in this context.

You can certainly write good, maintainable CSS and I’m sure tools like Vanilla Extract make it easier but to say tailwind is worse is just wrong (in my experience, anyway).

View on HN

I work in React so all of our CSS is scoped, at the very least with CSS modules, so we never get to a point where we have global CSS, at all. If you're working on a project that uses global styles, then yes, it will be extremely painful.

But in the days of components, Tailwind simply is worse to me from a maintainability perspective than just having scoped CSS. It is at best equal to CSS classes because inevitably the pattern used is with @apply or making a space separated string of all the Tailwind classes in JS in order to add that as a variable to whatever div you needed to. Which is, well, CSS classes reinvented.

And many people don't work in components or scoped CSS. Utility classes help so much in those cases.

The only problem with tailwind is it goes super overboard with the idea. You want to use probably 30% of tailwind and use their naming convention. But once people start to write some long on demand single classes its always better just name a class and use CSS.

I think its because the authors need to be seem they are making updates all the time and can't accept that it's pretty much finished project. They also don't want to accept that utility classes are not solution to everything and good old CSS still has lots of use.

Sure, I agree with you there.

What I’ve found from our Tailwind codebase is this:

If you have a design system, Tailwind.config can be used to both extend and limit the classes. Notably, we cut all tailwind colors out and only define theme colors. We also define all sizing, shadows, and text styles around our design system. This constrains your design down to only “legal” values. This doesn’t mean every design will be magically right, but it separates the possibility of non-standard values out at the very least and has actually caught bad mocks as well.

I think, to me, tailwind isn’t done and I need one thing: let me group classes with modifiers.

I want xl:[text-bold p-4] instead of xl:text-bold xl:p-4

Ultimately I don’t think tailwind is perfect at all…but no CSS framework is. In fact, I think part of the reason it is a hit is because mixing custom components with both custom css AND bootstrap is a mess as well in the real world. At least Tailwind has a single source of truth.

If you look how marketing teams / agencies use tailwind its exactly for it's ability to customize. Utility frameworks in the past (like Tachyons) were not very useful for them because they didn't have the customization. Every project starts with config and many things are turned off. Not only colors but also for example typography is too constrained in TW by default and it's better to make your own utility classes for likes .text-xl (because of media queries).

Your example xl:[text-bold p-4] is performance anti-pattern. Don't forget that main reason utility classes came to be was performance. It's fastest to put class directly on element and you end up with very small css file because you don't repeat. When you start to do xl:[text-bold p-4] you will end eventually write xl:[text-bold p-4 pb-2] or even xl:[p-4 text-bold]. Now you lost one of the main advantages of utility classes and end up in more confusing world than pure css.

I’m fine with a find and replace at build time with xl:text-bold xl:p-4 for that very reason, that would be my expectation.

Yes you can make utility classes for typography styles..that’s entirely the point of extending the framework, they are extremely clear that you should even. None of this precludes the idea that it is configurable to the point of making it a better solution for one’s needs.

Personally the vanilla extract example looks like literal boilerplate hell for any sort of actually complex application. It might make complete sense if the whole thing was based on a declarative template where the objects also define elements but here it is just SCSS done elsewhere.

The reason why people like Tailwind at build time is that it removes a step of defining classes out of the flow and puts all your styles in one place. That is the innovation: mental, not technical. I have a pet theory that Tailwind is more preferred by those with ADHD as it completely removes a mental blocker element.

VE is a SCSS substitute for those that like TypeScript instead of SCSS as a language, you can do the same stuff in either one. They even have custom utility classes too. Why I like it is it enforces a design system onto your code. In the Tailwind world the library CVA does the same thing so it's not a novel concept.

Twind could help you there:

https://twind.style/grouping-syntax

Why use @apply if your CSS is component scoped anyway.

Additionally, CSS Modules is not a replacement for TailwindCSS. TailwindCSS ships and strongly promotes the use of design tokens. It is harder to NOT use design tokens in TailwindCSS.

Because of this, there is no CSS Modules v. TailwindCSS. It is CSS Modules + X v. TailwindCSS. Where in the worst case "X" is just a stand-in for "everybody does whatever" which produces horrendous unmaintainable stylesheets whether they are global or not.

Reply on news.ycombinator.com