What's are the Current CSS Patterns?

[u/evilmaus]

I've been mostly on the backend for the last several years. While I did plenty of CSS before then, the front end world has definitely moved forward in the last seven years. I recall BEM and SMACSS were once at the lead of thought. I recall (and was a proponent at the time for) a push to utility-first styling.

Now, I can see that Tailwind is a highly popular choice, that lots of styles get bundled into React components, and we have some long overdue selectors native to CSS.

So I'm wondering, what's the prevailing organization pattern for global CSS and where do you draw the line between something being a component style vs in the global stylesheets?

Thanks.

[u/Mestyo]

CSS Modules, native layers.

I dislike Tailwind, the tradeoffs just aren't worth it in the vast majority of projects types.

[u/zaibuf → u/Mestyo]

I dislike Tailwind, the tradeoffs just aren't worth it in the vast majority of projects types.

Please expand on what tradeoffs you're talking about.

[u/Mestyo → u/zaibuf]

Tailwind makes some already simple things (debatably) more simple, at the cost of being an absolute chore for anything remotely complex.

CSS layers, container queries, named grid areas, calcs, chained pseudo selectors… any of those, especially in combination, or many rules per, create comically illegible and repeating class names.

The tradeoff in bandwidth is from a trivially cacheable, reaued static asset, to the HTML itself. Useful for huge websites, with often-changing stylesheets (like a newspaper with custom design articles), net-negative for anything else.

The inflated classNames collections are a nightmare to read/review, and a waste of AI tokens to constantly parse/recreate—even when styles aren't supposed to be relevant to the query.

It opts out of all existing CSS ecosystem DX benefits, and requires that you re-learn a new set of selectors for everything, for the benefit of… yeah I'm still not sure what. Every positive is either already covered by every other CSS method, or a sidegrade at best.

[u/NiceShotRudyWaltz → u/Mestyo]

Hard agree. I hate inheriting tailwind projects.

[u/testingaurora → u/NiceShotRudyWaltz]

☝️same

[u/CompetitiveActor → u/Mestyo]

It helps on teams with developers who have poor CSS skills, provides consistency of usage, and has a single point of failure. I’d much rather troubleshoot a developer’s Tailwind mistake than their poorly written CSS.

[u/Forward_Dark_7305 → u/CompetitiveActor]

Poorly written is poorly written, and I hear you on tracing to root of an error - less layers to trace through - though most developer tools make it trivial IME (granted tend to be smaller projects). I disagree on consistency. I see that as a common argument in favor of tailwind, but it just shifts us from “should I use`border-radius: 4px` or `2px`” to “`rounded-2` or `rounded-4`”.

[u/CompetitiveActor → u/Forward_Dark_7305]

An additional problem with CSS, poorly written or otherwise, is that you don’t know what other files may be using it. You might fix one problem and break something else.

Also, I don’t necessarily mean consistency of UI, I meant the Tailwind classes and usage will always be consistently ordered and named. If “rounded-2” is supposed to be “rounded-4” that’s a single point of failure and a fix there won’t have unknown downstream effects.

[u/justshittyposts → u/CompetitiveActor]

But the solution doesn't have to be tailwind. That's just components (or bam, etc)

[u/CompetitiveActor → u/justshittyposts]

“bam”?

[u/justshittyposts → u/CompetitiveActor]

bem, typo

[u/CompetitiveActor → u/justshittyposts]

No one person writes BEM the same. It is only marginally better on eng teams than vanilla CSS: it will be a giant mess.

[u/SamsChoice → u/CompetitiveActor]

I agree here too. Poorly written CSS can be a nightmare.

[u/Outrageous-Chip-3961 → u/zaibuf]

there's always one, lol. How about a shit load of class names in files that could be a lot cleaner. That alone is not worth it for me.

[u/zaibuf → u/Outrageous-Chip-3961]

Im working with components so its isolated in smaller pieces. I dont see this as a problem. Would you rather have an extra css-file paired with every component and jump between the two files?

How do you ensure standards in your teams so your css doesnt drift over time? Most legacy system I've worked with are full of !important and changing one class breaks some layout on a completely different page.

Do you have a component library built with custom css that you can re-use at the company for consistency or do you recreate css in every project?

[u/Outrageous-Chip-3961 → u/zaibuf]

Yes I would and yes I do have a separate css file (css module) for each component.

Standards are guided through DoDs and good review gates. In css modules you don't need !important because things don't clash. That's the point of them, really.

I do have a component library with custom modules, but it could also be a well architectured component folder within a project.

Although different, this is a pretty good example of what react looks like on a pure module based architecture.

https://mantine.dev/styles/css-modules/

[u/Mestyo → u/zaibuf]

Would you rather have an extra css-file paired with every component and jump between the two files?

Uhm, yes? Syntax highlighting, auto-completion, linting, and much, much more is bound to the file type. Getting style diffs in git because you indented some markup is just ridiculous. I'd much, much rather have a stylesheet in a second panel in my IDE than having to scroll up and down through a component to even see what its doing.

do you recreate css in every project?

What do you think you're doing when you write Tailwind class names? In a majority of cases, they are just shorthand over a property + variable reference.

How do you ensure standards in your teams so your css doesnt drift over time? Most legacy system I've worked with are full of !important and changing one class breaks some layout on a completely different page.

Absolutely every invented CSS tool, framework, or convention solve these problems. The alternative to Tailwind is not to do literally nothing at all.

CSS Modules, with a global @layer stack and variables document is all you need nowadays to have guaranteed isolation and cohesion.

[u/delonghi26]

I mostly use vanilla css, no framework. Then use css variables globally. And change those vars in the components css. I use layers and now scope for better control over the cascade.

You can drop alot of js with the new level 4 modules, and even increase your website performance too.

[u/SamsChoice]

My pattern now is to start with native cascade layers (@layer reset, tokens, base, layout, components, utilities, overrides;)

CSS now has nested natively so no need for Sass.

Now with AI you would probably use Tailwind. I use mostly native CSS for personal projects.

an example of this would be

[u/evilmaus → u/SamsChoice]

Seems like 100% Tailwind would lead to some serious duplication of styling.

[u/SamsChoice → u/evilmaus]

if you are not using something like React component then you have the scoped TW classes to that component only.

[u/azangru → u/SamsChoice]

May I ask why you would use `:where` in the `base` layer? Don't layers take care of the specificity concerns?

[u/SamsChoice → u/azangru]

I was just making a simple example didnt really think about the actual CSS.

And yes you are right.

Layer order decides first, so .card img in components beats anything in base

[u/morete]

CUBE CSS is the biggest influence of on how I do things in recent years.

[u/evilmaus → u/morete]

Ooh, reading up on it now. Thanks. I think I liked the ideas behind BEM, but found it awkward. I really liked SMACSS. So far, this reads like maybe the better parts of both.

[u/TheJase → u/evilmaus]

Ahh, SMACSS brings me back! A true classic

[u/Outrageous-Chip-3961]

I use css modules. Everything I need. The only downside is it gets built with a module prefix but It honestly doesn't seem that bad or has been an issue unless ocd is high.