Hacker News Reader

Comment by laurencei | Hacker News Reader

I'm a "full stack" developer. Largely a backend dev who does frontend as required, including on side projects.

I switched to TailwindCSS a long time ago and I have zero regrets. Its so awesome I can switch to a project that is 2 years old, and make a quick layout UI change without having to look at old CSS files to find classes etc. I also can just find a tailwind class name and apply lots of cool stuff that I've normally found difficult to do via "pure" CSS files.

But I also feel that this is likely to be a thing that half prefer A, and half prefer B, and there is nothing wrong with either. In this thread is likely to be a 50/50 split between both camps, with different "ideologies" on how the front end should be done.

As the author of this article says - give it a go. If you like it, awesome. If you dont, switch back to another tool, there's not a definitive "right/wrong" answer to any of this.

View on HN

That's how I see it - as a sole developer on a side project, Tailwind is a great force multiplier, much like tools like Hotwire/Turbo, Dokku/Heroku for deployments, frameworks like Rails or Django etc.

A large company with frontend specialists and CSS experts might not need Tailwind - and indeed they might find it gets in the way. Personally I find it lets me build and maintain decent UI layouts with minimum fuss. When I'm repeating myself with too-long class strings, I can either use @apply or wrap the markup in a component.

I had the experience of using a similar Atomic CSS framework to a large-ish company in the past, and maintenance was pretty smooth too. In fact I would say that maintainability was the #1 advantage for us in the long term.

Some people did have a visceral hatred of Atomic CSS, but even those people were able to solve problems with it very quickly, without having to dig on tens of CSS files that happened to affect a single component.

Is it normal to have tens of CSS files impacting a component!? In my world, the component styles itself, and its parent can tell it how to be spaced / positioned and themed (via CSS variables preferably). Anything beyond that seems spaghetti...

Of course it's the worst kind of rotten spaghetti. But yes, this is normal when projects are 10 years old, super large, and have been touched by 200, 300 or more developers.

There's only two ways to avoid it: having very small, very cohesive, teams, or using tools and methodologies that avoid this.

I've mainly seen this happen when the site/application is very product/design (non-tech) driven and the developers pull themselves and the code into contortions to deliver very exacting requirements. The goal is to deliver a pixel-perfect result at the end of the sprint, and the unfortunate waste product is the mess of CSS, markup and JS required to deliver it: which then becomes very fragile technical debt that can only be tweaked rather than refactored lest the whole stack of cards collapses. It makes little difference whether the team started out with a UI framework or not at this point.

True! Pixel-perfect layout at any cost is harmful to the long-term quality of the codebase. The development team has to be able to say "no" sometimes.

Fair enough, I work in small teams and independently a lot. It does make sense you need some strict architecture / tooling to prevent it in a more distributed org.

This is one of those things that gives me the feeling the true "10x" engineer mostly just writes code to some reasonable architecture standard and does their best to avoid tech debt. Speed in the longer term means avoiding these situations if you ask me

> ... without having to dig on tens of CSS files that happened to affect a single component.

Hmm, that would be interesting data to use to analyze the CSS quality of a site. If you used the sourcemaps along with a rendered html page you could find which elements had styling from the most separate css files which might give you clues on where to improve your CSS.

I’d say even at a large company this can be advantageous. Since most devs are moving into fullstack, it’s obvious to me when more backend centric people are doing frontend. I’d rather they reach for standard classes than do their mish mash of css brainstorming.

Disagree with 2nd statement. Tailwind is awesome for frontends, the way forward is to learn to compose. As long as you use bem style convention, with simple "flat" selectors, you can use both sass and tailwind and write less css (instead of no css, which I find extreme and impractical).

However that also means its perfectly ok to have one’s own system (cf. twitch, github...). Why not use a standard though? Tailwind saves us so much time coming up with a solid consistét utility set.

And then combine it with Sass

I would add this.

If anyone familiar with how Tailwind works lands on a new project, regardless of its age, this person can immediately understand the front-end code in a matter of seconds, without having to look through thousands of lines of code in a separate CSS folder.

I don't understand why Tailwind is "harder to read", as the OP wrote. It makes it much easier to read as what the code does is immediately understandable.

I think it's because Tailwind is forced via a mountain of historical baggage to shove it's entire UI in-between two quotes with a tiny (practical) character limit when you might really like some tooling (IDE collapse, expand, summarize, tag) and some browser support (dynamically compiled styles).

Some people consider tailwind/inline styles to be easier to read because it's all right there in the file.

Others view compartmentalisation as important to ease of reading, letting them focus on one level at a time.

I wonder how well the preferences for tailwind align with people's views on unit tests in the same source file?

Using Tailwind does probably establish a floor on the difficulty of quickly diving into a new project (assuming the Tailwind config hasn't been customized too much). That might be great if you're in the position to force your team to switch from unstructured/undisciplined CSS to Tailwind, but not in a position to force your team to use some even more structured approach that supports even better consistency and composability (like a set of components). Granted, Tailwind is probably intended to be used to create a set of components, although a lot of their official messaging (like Tailwind UI) seems to actively work against that approach.

That is simply untrue. Tailwind is great, but someone who isn’t proficient in creating css layouts is not going to magically understand the same layout with tailwind classes.

I had to eg. fix a stacking context issue (z-index) a so called full stack dev could not solve. Basic css technique.

For someone creating layouts from scratch tw is very verbose and templates can become difficult to reason through while you develop them. Easy to disregard for devs who just jump in a ready made template and make smaller changes.

I think you’re spot on - development is a big tent and it’s totally cool for this to be personal preference.

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.

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

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.

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

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.

Reply on news.ycombinator.com