I believe acss.io is the first usage of “Atomic CSS” where the point of it is to be a compiler. You write CSS like this:
<div class="C(#333) P(20px)">
text
</div>
And it will generate CSS like:
.C\(\#333\) {
color: #333;
}
.P\(20px\) {
padding: 20px;
}
(Or something like that.)
The point is that it only generates the CSS that you actually need, because you asked for it, and no more. The result is far less CSS than you’d see in an average stylesheet.

That compilation process is what has come to be known as “Just in Time” CSS.
The popular Tailwind framework supports it. It kind of flips the mental model of Tailwind on its head, to me. Rather than providing a huge pile of CSS utility classes to use — then “purging” what is unused — it only creates what it needs to begin with.

I’d say “Just in Time” is a concept that is catching on. I just saw Assembler CSS and it leans into it big time. Rather than classes, you do stuff like:
<div x-style="grid; gap:1rem; grid-rows:1; grid-cols:1; sm|grid-cols:3">
<button x-style="^button:red">Submit</button>
</div>

I’m pretty torn on this stuff. Some part of me likes how you can get styling done without ever leaving your templates. And I especially like the extremely minimal CSS output since CSS is a blocking resource. Another part of me doesn’t like that it’s a limited abstraction of CSS itself, so you’re at the mercy of the tool to support things that CSS can do natively. It also makes HTML a bit harder to look at — although I certainly got over that with JSX inline event handlers and such.
Yeah, but Tailwind JIT might be the best of both worlds. You have hundreds (thousands?) of helpful, predefined classes at your disposal, but it only spits out the classes you end up using. JIT is a game-changer and apparently Tailwind v3.0 will go even further.
I am not a bit fan of “inline” styling where the css in javascript is written inside the jsx. It sounds great to start with, but then you have hover effects, keyframes, focus-visible styles, animations, etc. ♂️
How Tailwind JIT works is much more fascinating to me. As you have already mentioned in your last paragraph, we have actually passed the line of discussion on ‘what the HTML should look to be a beautiful syntax’ when we adoptd the idea of JSX. I just like the idea that, its much more easier to manage a design system and I dont have to shift between different files to check if my box is at center of the screen.
I am far from fascinated from the Tailwind approach on CSS. So I feel kinda the same on this.
I believe CSS for a website should be a powerful engine. Maybe it’s difficult to write, and there’s plenty of things that can go wrong, resulting most of the time in heaps of unnecessary code or complexity. But we can succeed in building better systems with less code in other ways, with a good design, planning, optimization…
I’m not sure who’s gonna like to change hundreds of lines in the markup instead of modifying a well written CSS codebase.
Two other tools worth mentioning (and which in part motivated tailwind to add JIT mode):
WindyCSS https://windicss.org
Twind https://twind.dev
Desnecessary abstraction as Tailwind is.
Thanks for the shoutout for ACSS here. I’m pretty certain that ACSS was ahead of its time when it was created, something the CSS industry is only catching up in the last couple of years.
One more thing to note here, is that ACSS doesn’t have any predefined set of classes to choose from. This means you can generate classes with any arbitrary values like
P(21px)
,C(#f1f2f3)
and are not just limited to the values that other framework provides.ACSS doesn’t dictate any styles/values and has uglification built-in to produce much leaner and thinner CSS files.
I don’t get it… Why using weird abbreviations in the class property for the need of a transpiler, instead of writing just classic inline styles?
Ignoring principles like DRY or SoC is possible, but imho not meaningful.
Some attempts on just try not to write good old CSS reminds me on the famous programming language Brainfuck and other occupational therapies.
And another point of failure in your codebase …
firsr of all, I must say I don’t know this tool, and maybe what I will said is obvious. I work with LESS, and write all my CSS classes from scratch. I do modular scopes of the code, and don’t worry about CSS length. For example: “.mod_featured”.
…How this can understand that y want to scoope all CSS classes under? Also, I use common classes inside, for example: “.com_title_big” plus global design classes like: “.des_gutter”
More than this, I think is better to get all CSS in one file, because it has been readed and cached on browser once. I’m losing something? should change my mind on small/mid sized projects?
PD: I love so this site, thanks for it. Has a lot of tech info and helps me a lot for my daily work
It’s due to the recent shift (especially if you’re concerned with SEO) of only including Css that is actually used. Having one big css file was the norm, but that also means that a lot of Css goes unused. Ideally, you want to only load the css that is used on the page. These tools aim to provide that.
Am I missing the point here? It’s just inline CSS right? The point of CSS classes is that they’re reusable.
I think it’s a little more nuanced than that.
https://frontstuff.io/no-utility-classes-arent-the-same-as-inline-styles
That’s exactly what I was thinking.. that there is no difference between this and inline styling. Maybe there’s a performance gain?
I feel the same way.
What will be the befit in declaring every specific CSS attribute in the HTML elements rather than just create a CSS class to incapsulate what should be reusable?
I think Jon may be getting at the fact that Assembler’s syntax specifically looks a lot like plain CSS syntax, but with a few dynamic additions like named breakpoints (e.g.
sm|
) and the caret symbol (^
), and I’m sure several if not many others.The point is to not have any expendable CSS, which seems nice. But yeah, I too am skeptical of this approach as it 1) makes it difficult to use a coherent, predefined design system and 2) you have to learn a whole new syntax (I’m just tired, man!)
But I think it’s still in its early days and hope this issues will be adressed in a near future.
I’m torn by much of the same. There may be some convenient advantages to including utility classes to the HTML like this, but this breaks the flow and mental model of development over all for me, and I think this could really complicate the divvying up of work on actual corporate teams. I often develop intrinsic styles like special classes and built-in HTML elements so copywriters can create pages in plain HTML without knowing a lick of CSS and still create a fully branded pages because the CSS will simply apply to those elements used, without needing any inline styles or utility classes.
I grew up in the Bootstrap days, and Tailwind seems more meritable in some regards, but I still don’t know that I’d use it (or Bootstrap) for any production development projects where non-developers may need to construct pages. Either that, or I would need to ensure any non-devs took a course in HTML, CSS, and Tailwind (w/ JIT) before beginning their work.
This is the first I’ve heard of the “Just in Time” moniker for CSS and I really like it. It was always difficult to illustrate how ACSS was more than just Atomic CSS. I used ACSS extensively in the past on personal projects because I loved how lean the CSS was. It was extremely difficult to theme though and required the entire team to shift their idea of CSS authoring so I never ended up using it professionally.
Aside from theming, the other weak point of ACSS is its developer experience imo. As SPA frameworks have taken over the CSS-in-JS tools are JUST SO EASY TO USE but I don’t always love their output.
Now that we have custom properties for theming, I’d really love a tool that marries the DX of CSS-in-JS with the output of JIT that integrates seamlessly with IDE’s and the normal PostCSS toolchain.
One can dream :)
This is such a cool space. I’m even working on my own take: https://particlescss.netlify.app/
It’s not ready for production, but hopefully I can find a nice cross-section of easy to work with, supports plain CSS, and also has good DX for reusability and other stuff.
The big selling point of JIT CSS seems to be that it can reduce the size of a style sheet by only including the utility classes that are being used. However, it still doesn’t address the additional bloat it adds into the HTML. Without utility classes, I have one class that can be used on multiple elements on a page. With utility classes, most developers end up using the same 10 utility class names for every one of those elements. Debugging design problems and trying to find real HTML content among the hundreds of class names in a large project is frustrating.
I remember when industry leaders like Zeldman, Dave Shea, and Roger Johansson first warned about mixing markup and styling and encouraged semantic design. HTML5 was birthed from the idea of creating more semantic elements, removing stylistic tags, and making a future where the HTML served the sole purpose of marking up content while CSS added design to that markup.
I understand that times change and the web is being used for more than simple web documents, but the principles are the same. Why are we repeating the mistakes of the past where our markup is virtually unreadable due to the ridiculous number of
<div>
tags that exist only to attach a truckload of class names. It seems that developers simply can’t be bothered anymore to plan their applications with repeatable patterns that translate into singular class names that serve as hooks for their styles.This is one complaint I’ve never understood. Using jit/atomic/utility CSS isn’t incompatible with using semantic class names. I usually drop BEM-style class names on everything so I understand the context and then the atomic names trailing after it. (I usually don’t have any CSS behind the BEM names.)
Atomic CSS works well for my situation and may not work well for yours. I work on many different projects, and since our team uses atomic I don’t have any CSS to learn/remember in order to start working right away without worrying about breaking something.
I wrote a gulp plugin for compiling HTML class attributes to atomic css in 2014. Since it was never popular I don’t think it deserves any historical recognition – I just offer it here as an oddity:
https://github.com/internetErik/gulp-atomicscss
I used emmet CSS abbreviations as my syntax, as well as some added syntax for hover, breakpoints, and optionally grouping some classes together under one tag. I’m not even sure if I left it in a working state, but would be easy to fix up.
I found it easier to just generate my own atomic classes from a configuration file I write in scss along with a small library for this purpose that I made:
https://github.com/internetErik/atomic-scss
The biggest benefit of using “Utility-First” styling with “JIT” compiling, is enforcing a style-guides unit sizing system (REM’s, EM’s, and Pixels).