# Grommet: a React component library where theming is the API

> Grommet is an Apache-2.0 React framework whose theme object drives colour, spacing, typography and component behaviour. It suits design-system teams that want one JSON-shaped source of truth, and it is a poor fit for anyone who wants a small dependency.

**grommet/grommet** — a react-based framework that provides accessibility, modularity, responsiveness, and theming in a tidy package

- Repository: https://github.com/grommet/grommet
- Website: https://grommet.io
- Stars: 8,348 · Forks: 1,036
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/grommet-grommet

## What Grommet solves for React teams with a design system

Most React component libraries ship a fixed visual language. You get buttons that look like the library's buttons, and changing them means overriding CSS or wrapping components. Grommet takes the other position: the theme is a first-class input, and the components read their colour, spacing, typography and behaviour from it. The README frames the project as a framework that provides accessibility, modularity, responsiveness and theming "in a tidy package", and the repository layout backs that up, with a src/js/contexts/ThemeContext/ directory listed in package.json's sideEffects array, which is where the theme reaches the tree.

The audience is narrow on purpose. This is for teams building an application interface in React who already have, or intend to have, a design system: a set of tokens and rules that several screens must obey. If one person is building one page, the theme layer is overhead you will not use. If five teams are building forty screens, a single theme object that all of them import is the reason to pick this over a component kit that hardcodes its look.

## How the theme object reaches every component

The mechanism is a React context. package.json declares sideEffects for ./src/js/contexts/ThemeContext/ThemeContext.js and its es6 counterpart, which tells bundlers that this module has effects and must not be tree-shaken away. Components consume the theme through that context rather than through props passed down by hand, so a single provider near the root changes the appearance of everything below it.

The build produces two module formats. The main field points at index.js and the module field at es6/index.js, with jsnext:main as a legacy alias for the same path. The build script runs webpack in production mode, then Babel over src/js/ into dist/ for the CommonJS output and again with BABEL_ENV=es6 into dist/es6/ for the ES module output, copying non-JavaScript assets alongside. Practically, that means your bundler can pick the ES module build and still tree-shake, as long as the sideEffects entry keeps the theme context alive.

Node 16 or newer is required, per the engines field. That is a low floor and worth noting only because it tells you the project is not chasing the newest runtime features.

## Installing Grommet and rendering a themed first screen

The README gives two install paths. Both bring styled-components along, because Grommet's components are built on it, and both are the whole install step. For npm:

```bash
npm install grommet styled-components --save
```

For Yarn:

```bash
yarn add grommet styled-components
```

After that, wrap your application in the provider and pass a theme. The README points to the Grommet Starter app tutorial for new applications and to a separate Existing App guide for adding Grommet to something already running. What you should see once the provider is in place is that component appearance follows the theme object rather than any stylesheet you wrote.

To browse what each component looks like before you commit, the README documents running Storybook locally:

```bash
npm run storybook
```

or with Yarn:

```bash
yarn storybook
```

There is also a hosted Storybook and a CodeSandbox starter linked from the README if you would rather not run anything locally. One detail worth knowing before you wire up CI: the repository ships a stable branch, and the README shows how to point package.json at it instead of a version number.

```json
"grommet": "https://github.com/grommet/grommet/tarball/stable"
```

That tarball URL tracks a branch rather than a release tag, so it moves when stable moves. The README links a wiki page explaining what stable is, and if your build needs reproducible installs you should prefer the published version.

## Where Grommet is the wrong choice

The dependency footprint is the first honest objection. Grommet does not stand alone; styled-components is a required peer in both install commands, and that library brings its own runtime behaviour into your bundle. If your project has deliberately avoided CSS-in-JS, adopting Grommet means adopting that decision too.

The second limitation is that the README is thin on the things that decide adoption. It documents installation, Storybook, the stable branch and where to find the change log, but it does not document rollback, deprecation policy, or what happens to a theme when a component's expected keys change between minor versions. The change log lives in a wiki page rather than in the repository tree, which means it is not in your git history when you upgrade. For a framework whose main promise is theming, the absence of a documented theme migration path in the README is a real gap, and it is the thing I would want answered before a large migration.

Third, this is a React framework. There is no Vue, Svelte or web-component build documented in the README or visible in the repository layout. If your stack is not React, the question is closed.

Finally, accessibility is listed as a project goal and the repository carries an a11y topic, but the README does not make a conformance claim. Treat the accessibility work as something to verify in your own screens with your own assistive-technology testing rather than something the README certifies.

## Grommet compared with Material UI and plain styled-components

Material UI is the obvious comparison, and the difference is philosophical rather than feature-level. Material UI implements Material Design and lets you customise within that language; its defaults are opinionated and recognisable. Grommet ships no single named design language. It gives you components and a theme object and expects you to define the visual system yourself. If you want to look like Material Design, Material UI gets you there faster. If you want to look like your own brand and you have designers who will specify tokens, Grommet gives you a shorter path from those tokens to rendered components.

Against using styled-components directly, which Grommet depends on, the trade is different. styled-components gives you a styling primitive and nothing else: no accessibility behaviour, no responsive props, no component set. Grommet is the layer above that. Choosing Grommet over raw styled-components is choosing to accept its component APIs and theme schema in exchange for not writing them. The cost is that you inherit its release cadence, currently visible as v2.57.0 on 2026-09-14, v2.56.1 on 2026-08-18 and v2.56.0 on 2026-07-29, and its decisions about what a component's props mean.

## Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-21. Releases in the recent window land roughly monthly, with patch releases between them. That is a cadence you can plan upgrades around, though the README itself does not state a support window for older major or minor lines, so nothing in the README tells you how long a given version keeps receiving fixes.

The upgrade cost is concentrated in the theme. Because components read from the theme context, a change to expected theme keys between versions can surface as a visual regression rather than a compile error, and the README does not describe a migration tool or a theme version field. The change log is the place the project points you to, and it is a wiki page. Reading it before each bump is the practical mitigation.

On licensing, package.json declares Apache-2.0, and the repository carries both LICENSE and COPYRIGHT.md, with the build script copying them into the published dist output. Apache-2.0 is permissive and includes an explicit patent grant, which matters if you are shipping Grommet inside a product. It also carries notice requirements, so if you redistribute the built output you should keep the copied LICENSE and COPYRIGHT.md files intact rather than stripping them from your bundle. That is a description of the licence text, not legal advice; your counsel decides what your distribution requires.

## Conclusion

Adopt Grommet if you are building a product surface in React and want a documented theme object to be the contract between design and code; the npm install pulls in styled-components as a peer, so budget for that. Do not adopt it for a static marketing page, a non-React stack, or a bundle where every kilobyte is negotiated, because the theme machinery and the component set are the point and you pay for both. Before committing, read the Change Log wiki page for the jump between your current version and 2.57.0, and check the stable tarball URL if you want releases decoupled from master.

## FAQ

### What is Grommet?

Grommet is a React-based framework that provides accessibility, modularity, responsiveness and theming, licensed under Apache-2.0. The README describes it as focusing on "the essential experience", and it is installed alongside styled-components.

### How do I install Grommet in an existing React app?

The README gives npm install grommet styled-components --save or yarn add grommet styled-components. For adding it to an application that already exists, the README points to a separate Existing App guide rather than the new-app tutorial.

### Does Grommet work with Yarn?

Yes. The README documents yarn add grommet styled-components as an alternative to the npm command, and also shows yarn storybook for running the component examples locally.

### What Node version does Grommet require?

The engines field in package.json specifies node >= 16. The README does not restate this, so the package manifest is the source.

### What is the grommet stable branch and how do I use it?

The README states that a stable branch is built from the content of the master branch, and shows pointing the package.json entry at https://github.com/grommet/grommet/tarball/stable. It links a wiki page titled "What is grommet stable and how to use it?" for more detail.

### Where can I see Grommet component examples before installing?

The README links a hosted Storybook and a CodeSandbox starter. It also documents running the examples locally with npm run storybook or yarn storybook.

## Sources

- [grommet/grommet on GitHub](https://github.com/grommet/grommet)
- [License: Apache-2.0](https://github.com/grommet/grommet/blob/master/LICENSE)
- [Project website](https://grommet.io)
- [README](https://github.com/grommet/grommet/blob/master/README.md)
- [Releases](https://github.com/grommet/grommet/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/grommet-grommet