A list of all CSS toolchains ever made (parsers, preprocessors, and transformers, NOT style kits like Bootstrap).
| Name | Description | Created | Deprecated | Notes |
|---|---|---|---|---|
| Sass | GOATed preprocessor | 2006 | One of the oldest preprocessors still going strong in 2025, and has kept up with the times! | |
| LESS | Other popular preprocessor | 2009 | Still maintained, got a major uptick from Twitter Bootstrap, but you don’t see it as much as Sass. | |
| Stylus | Indent-based CSS preprocessor built in Node.js | 2011 | 2024 | Precursor to the Node.js wave of tools. Being too opinionated (unlike PostCSS) may have hurt its adoption, though some of its parsers did creep into later projects like Glamorous. |
| PostCSS | A build-your-own CSS language ecosystem | 2013 | Paradigm shift to Node.js-dominated tools. There are multiple projects like Autoprefixer which converged into PostCSS which have storied histories I won’t outline here. | |
| ACSS | Atomic CSS toolchain | 2015 | 2022? | Still maintained, but largely seems to be eclipsed by Tailwind in 2025 (who credit ACSS as inspiration). |
| Aphrodite | CSS-in-JS solution | 2015 | 2018 | Another CSS-in-JS prototype. Its popularity came from the fact that it predated most other solutions, but was eventually outpaced by Styled Components / Emotion. |
| Styletron | First-attempt CSS-in-JS solution | 2016 | 2018 | Amidst the explosion of competing CSS-in-JS frameworks, this had a clunkier API. Was an inspiration for other frameworks, but more of a proof-of-concept for others to improve on. |
| Fela | CSS-in-JS that generates atomic CSS | 2016 | 2022 | Ambitious project that tried to not only handle runtime (which was tricky enough) but also handle CSS optimization on-the-fly. Never reached the “Holy Grail” solution but not for lack of trying. |
| Styled Components | Most popular 1st-gen CSS-in-JS solution | 2016 | 2022? | Technically still maintained, but usage has dropped since React Server Components which are incompatible. |
| Radium | Another early CSS-in-JS solution | 2016 | 2020 | Simply lost popularity contest to Styled Components/Emotion for unclear reasons. |
| Glamorous | Merged into Emotion | 2017 | 2018 | |
| Emotion | Styled Components’ successor | 2017 | 2022? | Also unofficially a dead end. |
| Stylable | CSS Modules implementation with a few quality of life improvements | 2017 | 2022? | A weird departure from CSS Modules. Still in use by Wix but has been partially-deprecated. |
| Styled JSX | Thin wrapper around CSS Modules designed for Next.js’ SSR | 2017 | Simple, elegant approach to give a little more utility over CSS Modules when using Next.js. Not too overengineered, but may leave some wanting more. | |
| Linaria | Zero-runtime CSS-in-JS | 2017 | Arguably the first CSS-in-JS approach that prioritized CSS. Still actively-maintained, though it didn’t have the explosive adoption some other solutions did. | |
| Styled System | Framework for building design systems in CSS-in-JS | 2018 | 2019 | Influential in its approach, but possibly ballooned out-of-scope. Trying to maintain support for multiple other popular CSS-in-JS libraries likely led to burnout, and the React Server Components debacle. |
| JSS | Simple, no-fuss CSS-in-JS. | 2019 | 2022 | Still quite popular despite being unmaintained. It’s “dumber” than many other solutions, but that’s part of what’s given it staying power. |
| Tailwind | Atomic CSS | 2019 | Passionately-loved utility CSS framework (and equally-hated by others). Though it’s part style kit, part design system, Tailwind also is a toolchain which is why it’s listed here. | |
| Astroturf | Zero-runtime CSS-in-JS | 2019 | 2021 | Fizzled out. |
| Panda CSS | CSS-in-JS with runtime, but works with Server Components | 2019 | Still maintained, though there are still open issues and the roadmap is empty. Likely in “maintenance mode.” | |
| Stitches | (Almost) zero-runtime CSS-in-JS solution | 2020 | 2023 | Acquisition made maintenance hard (discussion) |
| tss-react | Extension on top of Emotion | 2021 | 2022? | Adds smarter features on top of Emotion, but being dependent on Emotion, is tied to the same fate. |
| Vanilla Extract | Zero-runtime CSS-in-JS, and successor of Stitches | 2022 | Possibly the most mature CSS-in-JS framework in 2025. Has framework adaptors like Sprinkles to make it even easier to use. | |
| Lightning CSS | Lightning-fast CSS parser/transformer written in Rust | 2022 | It’s more than a parser/compiler! It actually supports building your own CSS superset like @mixins) | |
| StyleX | A 3rd-gen CSS-in-JS framework nobody saw coming | 2023 | StyleX is an interesting framework that claims “no specificity issues” with some receipts to back up the bold claim. It also is very clear about its boundaries, in an improvement from previous CSS-in-JS failures. |
Since the famous 2014 talk on the problems of CSS, many open source solutions have attempted to solve the problems raised. The libraries that share these philosophies collectively became known as “CSS-in-JS,” referring to the way in which styles could more effectively be optimized when there was a more direct link to the markup using it.
The concepts of “1st-gen” and “2nd-gen” are made up by me to refer to recurring themes in the libraries.
The first wave of libraries—Styled Components, Emotion, and others—focused on mere proof-of-concept. They were the first to pioneer the approach and get it usable in production. But there were ultimately performance issues and design flaws, as outlined in one ex-Emotion maintainer’s bombshell blogpost.
The second wave sought to keep all the advantages of the approach while solving for performance, and led to “zero runtime” solutions like Linaria, Vanilla Extract, and others. This wave attempts to “have your cake and eat it too” by making it as performant as raw CSS, often through the use of transpilers and “compilers” (not in the traditional sense; the term “JS compiler” has come to refer to a number of techniques that involve producing more heavily-optimized JS beyond simple transpilation such as Svelte’s or React’s).
“Why is that missing from the list?” you might ask. Reason is that CSS Modules is technically not a toolkit; it’s not even a spec. It’s more an alternative strategy to CSS-in-JS, sitting somewhere in between vanilla CSS and runtime-integrated framework. Heck, even major implementations may differ like it does in Vite.
Most CSS Modules implementations rely on PostCSS, but under-the-hood almost every usage differs ever-so-slightly, and there’s not one canonical solution to point to.
Also known as “Utility CSS,” this refers to a strategy that tries to optimize CSS by declaring each property once and only once. Tailwind is currently the most well-known implementation of this philosophy. It’s still an open debate whether or not this produces more efficient CSS, and opinions on developer experience are mixed as well (some love it, some hate it).
The major opposing strategy to Atomic CSS is a “Semantic Framework” like BEM or SMACSS that preach tighter coupling with design system components. Here, the emphasis is on meaningful naming for CSS, believing that maintainability always trumps premature optimization.
Atomic/Utility CSS’ frequently-cited drawback is it makes responsive design very difficult, a problem that Tailwind has slowly chipped away at over years. Tailwind’s current status in 2025 is the core responsive design needs are handled, but some edge cases are still impossible to pull off (e.g. container queries).
“What gets mentioned? What gets omitted?” This is meant to be a list of toolchains. I’m defining a toolchain as “anything that transforms the output differently than authored.” For that reason, things like BEM, SMACSS, Bootstrap, Tachyons, and countless others are omitted. While they are CSS solutions, they are not toolchains because they merely guide you to author CSS in a particular way but do not transform or optimize anything written.
In other words, this list is significant because it can be seen as modifications (or supersets) of the core CSS language, rather than implementations or strategies. Also just for the purpose of archiving, including any/all stylekit or design systems would be overwhelming as they vastly outnumber the toolchains.
Lastly, there may be many toolchains that are closely-aligned with PostCSS, that may have accidentally or unintentionally merged with that project. If there are any that aren’t mentioned, either I just lumped it in with the csstools/PostCSS ecosystem, or I just hadn’t heard about it.