Griffel moves CSS-in-JS style compilation to build time

The runtime style engine is the thing Griffel removes

Griffel describes itself as CSS-in-JS with near-zero runtime, SSR support and styles defined with JavaScript objects. The last part is familiar: you call something like makeStyles with an object and the values are checked by the type system. The second part is where Griffel differs from the common way of doing this. A runtime CSS-in-JS library ships a style engine to the browser, and that engine has to walk your style objects, generate rules, and insert them into the document while the page is running. Griffel moves that work to build time. The styles you write still live in JavaScript, but the output that reaches the browser is ordinary CSS, and there is no engine to initialise on the client. That is the entire argument for the library, and it also means the benefit is only as good as your build setup.

Atomic CSS is the trick that keeps specificity out of the way

The README lists atomic CSS as one of Griffel's features, describing it as a way to reuse styles and avoid specificity issues with CSS. Instead of generating one class per component with all its declarations, an atomic approach generates one class per declaration. A component's style object produces a small set of single property rules that the component composes at render time. Two consequences follow. The browser gets rules with a single property each, so the usual cascade fight over which of two competing class rules wins does not arise in the same form, and identical declarations across many components resolve to the same class name, which shrinks the shipped CSS. Griffel also offers type-safe styles through csstype, so a wrong property name or a bad value is a type error rather than a silent style that never applies.

A zero config start, with two implementations of the same idea

The README advertises a zero config start and notes that Griffel has both runtime and build time implementations. That distinction is the one to understand before anything else, because it decides how much of the near-zero runtime claim you actually get. The runtime path works with no compiler configuration, which is convenient and gives you the SSR support without a bundler plugin. The build time path is where the compilation happens ahead of time, and the README lists optional build time transforms under a webpack loader, presented as a way to improve performance. The wording matters. The transforms are described as optional rather than required, so a project can start on the runtime implementation and move to the build time one later, or never. Nothing in the documentation frames the build step as a hard prerequisite, and treating it as one would misrepresent the design.

Webpack loader, extraction plugin and a DevTools extension

Three pieces of tooling surround the core library. A webpack loader handles the build time transforms. A separate webpack extraction plugin handles CSS extraction, and the README labels that feature experimental, which is an unusual word to see in a project documentation page and worth taking at face value. The third piece is a browser extension, Griffel DevTools, listed under the debug heading, which lets you inspect the styles Griffel has produced in a running application. A monorepo surrounds all of this. The repository root carries nx.json, a yarn.lock file, a .yarnrc.yml and a beachball.config.js, and the workspace globs cover e2e, packages and tools directories, so the packages are built and tested through a task graph rather than one script. That is a heavier machine than a single published library usually demands.

Installing Griffel with React, and what the docs expect you to read next

The documented install is a single package for React, and the README links out to a quick start page and an API guide rather than repeating the usage here, so most of the learning curve sits in the documentation site at griffel.js.org.

npm install @griffel/react
# or
yarn add @griffel/react

The repository itself is developed with yarn 4.15.0 as its package manager and declares a Node requirement of >=24 in the root package.json, which is worth knowing if you plan to work on Griffel rather than just consume it. The published package set is broader than the React entry point. The packages directory holds separate packages for the webpack loader and the webpack extraction plugin, and the top level of the repository also includes apps, e2e and tools directories, so the React package is one member of a wider set rather than the whole project.

Where Griffel sits against runtime CSS-in-JS

The alternative worth naming is the runtime approach Griffel is built against, where a style engine ships to the browser and injects rules as components render. The difference in approach is not about which style syntax you write, since both take objects, but about when the work happens. The runtime approach trades a smaller build for a client bundle that carries an engine and does work during the first paint. Griffel trades a compiler in the build for a smaller client and rules that exist before the page renders. The second is the harder path to adopt because it puts a build step and a bundler plugin between you and a working screen, and because the payoff is invisible until you look at the shipped bundle. The repository's own dependency list makes the lineage visible, since it includes a preset for a different ahead-of-time CSS approach alongside the styling libraries Griffel shares an ecosystem with. That is worth knowing before you choose, because the two families of tools solve the same problem with different compilers.

Release cadence, licensing and what the repository does not say

Griffel is MIT licensed, with the license text in a LICENSE.md file at the repository root and the trademark notice spelling out that use of Microsoft marks must not imply Microsoft sponsorship. The repository is not archived, and the last push was on 2026-10-14. There are no GitHub releases, which is typical for a monorepo where many packages version independently. The versioning process visible in the repository runs through beachball, and there is a change directory and a beachball hooks file, so change files are authored per change and released in batches rather than tagged one by one. What the README does not state is which browsers are supported, what the measured size difference is against a runtime library, or how the experimental extraction plugin is expected to change. For a library whose selling point is a performance difference, that is a notable gap, and it is the gap you close by reading the site and measuring your own bundle.

Editorial conclusion

Griffel fits teams that write React, want type-checked style objects, and can accept adding a build-time transform to their bundler pipeline. It does not fit a project that ships a zero-build setup, that wants a single dependency with no compiler configuration, or that is not on React, since the documented entry point is the @griffel/react package. Before you commit, run the optional webpack loader and the CSS extraction plugin on one screen, then check the emitted rules for the atomic CSS you expect, because the extraction plugin is labelled experimental in the project documentation.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/griffel on GitHub
4. Project website
5. README