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.

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.

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

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

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