Comment by ricardobeat | Hacker News Reader

Comment by ricardobeat | Hacker News Reader

Parent Full thread

I think there's more than personal preference at play here. The hidden benefit that the author missed is that Tailwind's (or any other atomic CSS approach) classes are immutable and all changes localized. This pays off hugely for large [enterprise] projects.

In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else. With class-based styles, even when using theme variables, there is always the chance you end up breaking something at a distance by adding a property to an existing class, changing a shared value, renaming a selector or changing it's precedence.

If you find yourself in this environment where dozens of people are making changes concurrently, and these issues are a daily occurrence, naturally you'll wonder how you ever worked with CSS any other way.

styled-jsx and other approaches can get you similar benefits but extra care is necessary. I mostly avoid Tailwind due to the lock-in, complex setup and slow build, otherwise might have used it for quick prototypes more often.

> In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else

Isn't the flip side of this that it makes it almost impossible to keep styles (visually) consistent across the codebase?

The opposite. Tailwind pretty much guarantees you’ve got consistent ratios, colors, etc across your product.

Our experience has been absolutely not with an inhouse atomic css framework we ultimately ripped out of a project. Something like pd-md (for "medium padding") gets applied somewhere, then the decision is made that e.g. buttons should have less padding unless they're in a dialog, so someone goes around replacing it with "pd-sm" on buttons except they miss some and other developers don't get the message and add new buttons still using "pd-md" as they just copied and pasted the styling from a button that hadn't been updated and all of a sudden different forms have different padding on all your buttons, something that wouldn't have happened if making a button was just applying class="button".

For me it makes sense to create a component class in that case, using Tailwind‘s `@apply` to add the generic padding:

    .button {
        @apply py-2 px-4;
    }

This ensures CI elements are styled the same way everywhere, but still relies on the Tailwind config to figure out what „2 abstract units of vertical padding“ mean in your application.

But then why not go all the way and do

    .button {
        padding: var(--medium-padding) var(--medium-padding);
    }

Or use LESS/SCSS/etc if the var(--) syntax is really that offputting.

No, I actually love CSS variables. But they invariably will be abused in the long term. What you called medium padding might suddenly be decreased to be a value lower than small padding, and that’s the point where it all starts to go to hell.

The point of Tailwind is that it’s a straightforward way to handle all the CSS complexity and put the moving parts into a single config file that works the same everywhere.

> What you called medium padding might suddenly be decreased to be a value lower than small padding, and that’s the point where it all starts to go to hell.

Tailwind: https://tailwindcss.com/docs/theme#spacing

Would it be strange to define p-2 to be smaller than p-1? Yes. Exactly as strange as defining your padding-medium variable to be smaller than padding-small.

I'm pretty skeptical about lock in. If I couldn't use tailwind tomorrow, I think I could rewrite the few dozen minimal utility classes I need in a matter of hours. IMO the implementation is a convenience.

The slow build is definitely an issue, although that's generally only a factor when you're customising Tailwind, not when you're just using the classes in your HTML. (I'm sure you know this, just adding it for clarification).

However, the Tailwind team are very close to releasing something that is, apparently, going to dramatically speed up build times (source: Adam Wathan's recent tweets).

The complete Tailwind bundle is 3MB in size - optimizing for production (pruning unused classes) is necessary even if you're not using customization.

Sure, but that's just part of the deployment process and adds a few seconds to it, it's not something that hampers you (generally) with development.

"In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else."

I sometimes wonder if people even understand what technology they are using:

CSS = Cascading Style Sheets

Go read some history, as to why exactly they were created. What you are describing is not CSS at all, that's properties on a design grid.

Which goes back to the author's point - if you want or really need that, don't use CSS. Just use components with standalone properties.

Use CSS when you want to be 100% sure it will change everything else.

Reply on news.ycombinator.com