I’m not the biggest fan of Atomic CSS myself. I don’t like all the classes. I like to express my styles in CSS because I find CSS… good. But I appreciate that a lot of people seem to like it, and it does have some clear advantages, like the fact that the generated stylesheet is generally smaller than hand-rolled CSS authored other ways—plus, the available classes are like guardrails that ensure more consistent usage in a design system.
I also appreciate that innovation is happening in this space. It seems to have gone from:
Here’s a billion classes you can use, but hey, at least the CSS is still fairly small and won’t change!
To:
Yes, that, but we’re going to strip away the ones you aren’t using.
And now:
We’re going to generate the stylesheet on the fly based on what you do use.
Anthony Fu breaks down this history nicely in “Reimagine Atomic CSS” where he then throws his hat in the ring taking things one step further with UnoCSS. I can’t say I fully understand it all, but it looks like it can do anything that its predecessors can do but more, largely via rule configurations. It’s also fast (based on vite), and I’m always a fan of fast tools—especially where the goal is a tight feedback loop.
It looks rather complex to me and seems to have limited integrations. I’m not a fan of the bit that turns styles into arbitrary HTML attributes. If they were, like, JSX props, that’s fine. But I think HTML attributes that go all the way to the DOM are dangerous and should be data-*
scoped.
At the same time, I always like it when people think through problems and share their thought processes for solving them like Anthony has done here. Plus, there is a playground and that’s fun.
From what I could gather based on the history of Atomic CSS, it was never created to reduce the size of the stylesheet (this just happened by design).
The original problem the guys at Yahoo were trying to solve was how to manage CSS in a large organisation that have a number of frontend teams working on different products scattered across the globe in different timezones with members of varying experiences and skillsets.
Atomic CSS was born in an attempt to solve some of these problems by consolidation of styles under a single architecture, no naming conflicts for CSS classes, reusability of same CSS across all products, less regression errors due to automatically generated classes etc., and many more which I’m probably forgetting.
Reduction in the size of stylesheet was just a happy byproduct of the design :)
Ha, looks like I invented Unocss a month or two ago, but thought I was just joking.
Actually, ACSS has been doing exactly that since 2014! But at the time, “Atomic CSS” was considered so bad that most people didn’t even bother trying to understand what ACSS was about :-(