segmentio/evergreen: a React UI framework built on ui-box

What Evergreen solves, and who is actually building with it

Most React component libraries ask you to accept someone else's spacing scale, someone else's colour tokens and someone else's idea of what a form looks like. Evergreen's stated position, in its own core values, is the opposite: it ships what the README calls "polished React components that work out of the box", but every component is composed from the Box primitive in ui-box, so the same component that renders with sensible defaults can be restyled down to the individual CSS property. The target audience is stated plainly in the README as "enterprise-grade web applications", which in practice means internal dashboards, admin consoles, settings pages and data-heavy tools. If you are building a marketing site or a highly bespoke consumer interface, the component vocabulary will fight you rather than help you. If you are building the fifth internal tool your company has shipped this year and you are tired of rebuilding the same select, the same table header and the same side sheet, this is the category of library you want.

How the component model works: ui-box underneath, CSS-in-JS on top

The mechanism is worth understanding before you install anything, because it explains both the library's flexibility and its bundle behaviour. Evergreen does not emit a stylesheet you import. It bundles its own CSS-in-JS solution from ui-box, and components are built on top of the Box component rather than on plain DOM elements. That means a Button is not a styled <button>; it is a composition of Box primitives with props that map to style values. The practical consequences are twofold. First, you can pass style props to components without writing a wrapper class, which is why the README describes composability as "endless". Second, styling happens at runtime, which is exactly why the library needs an explicit server-side rendering story: there is no static CSS file for the server to link. The package.json confirms the shape of the distribution, with separate commonjs, esm and umd builds plus a types entry, so the library is consumable from a bundler, from Node, or from a script tag via unpkg. The sideEffects field is set to false, which is a signal to bundlers that unused modules can be dropped.

Installing evergreen-ui and rendering a first component

Installation is a single package. The README gives both package managers, and the package name is evergreen-ui, not evergreen. Note that the repository is segmentio/evergreen but the npm package you install is evergreen-ui; confusing the two is a common first mistake when reading the repository name.

yarn add evergreen-ui
# or
npm install --save evergreen-ui

The README's working example assumes a setup like Create React App, where a root element already exists in the HTML. It imports Button from the package and renders it directly.

import React from 'react'
import ReactDOM from 'react-dom'
import { Button } from 'evergreen-ui'

ReactDOM.render(<Button>I am using 🌲 Evergreen!</Button>, document.getElementById('root'))

If that renders a styled button rather than an unstyled one, the CSS-in-JS layer is working. There is no stylesheet import to forget, which is the main reason the first-run experience is short. For server-rendered applications the extra step is real, and it is covered below.

Server-side rendering and the extractStyles() function

Because styles are generated at runtime, a server-rendered page would otherwise arrive unstyled and then repaint once JavaScript loads. Evergreen addresses this by exposing an extractStyles() function, which the README describes as the way to make "server side rendering and hydration" easy. The workflow is that you render your application tree on the server, call extractStyles() to collect the generated CSS, and inject that CSS into the HTML you send. The repository includes examples/ssr-next, a Next.js example app, and the README links a GitHub issue for the GatsbyJS case. The honest assessment is that this is a solved problem with a documented path for the two frameworks the README names, and an undocumented path for everything else. If you are running a custom Node server or a framework outside that pair, you are reading the extractStyles() signature and working it out yourself. That is not a defect specific to Evergreen, but it is the point where the "works out of the box" claim stops applying.

Theming, and where the flexibility turns into a maintenance question

Theming is a first-class feature rather than an afterthought. The README points to a dedicated theming section in the documentation and describes the layer as supporting full control when needed, which matches the core value about smart defaults with an escape hatch. The trade-off is that a theming layer built on runtime style generation is not free. Every themed value that differs from the default is work the browser does while rendering, and the library's own documentation is where the specifics of that cost live rather than in the README. More importantly for a team, a deep theme is a fork in all but name. Once you have overridden a large share of the design tokens, upgrading the library means re-validating your theme against the new defaults, and the codemods directory in the repository exists to automate the mechanical part of version upgrades, not the design part. Teams that expect to diverge heavily from the default look should price that in before adopting.

What Evergreen is not good at

The clearest limitation is release cadence. The most recent release listed is v7.1.9 from 2023-06-21, and the two before it are v7.1.8 and v7.1.7 from May and April 2023. The repository itself was pushed on 2026-06-25, so there is activity, but the published version history is not the history of a library shipping features every few weeks. If your project depends on a component that is missing, or on a fix to something that annoys you, the timeline for that arriving in a release is not something the README commits to. A second limitation is scope. The component set is aimed at enterprise applications, so you will find the controls an admin tool needs and you will not find the components a marketing page needs. Third, the CSS-in-JS approach means a runtime cost that a static stylesheet library does not pay, and it means the SSR path is mandatory rather than optional for server-rendered apps. None of these are reasons to avoid the library, but each is a reason to check it against your specific project before adopting.

How Evergreen differs from a utility-first approach like Tailwind CSS

The obvious alternative for a React team is Tailwind CSS, and the difference is architectural rather than cosmetic. Tailwind gives you utility classes and no components; you assemble a button yourself from a set of class names, and you own the markup, the accessibility attributes and the keyboard behaviour. Evergreen gives you the component and the behaviour, with styling exposed as props over a Box primitive. The practical split is where the work lands. With Tailwind, the work is front-loaded into building every control and it is paid again for each new control; with Evergreen, the work is back-loaded into theming and into accepting the library's opinions about spacing, colour and interaction. There is also a runtime difference: Tailwind produces a stylesheet at build time, while Evergreen generates styles as components render, which is why Evergreen needs extractStyles() on the server and Tailwind does not. Neither is correct in the abstract. If your design is unusual and your component count is low, Tailwind fits better. If your design is conventional and your component count is high, Evergreen removes a large amount of undifferentiated work.

Licence, upgrade cost and what the repository tells you about maintenance

Evergreen is released under the MIT license, which is permissive and imposes no obligation on your application's own licensing. One detail that is easy to miss: the README states that the BlueprintJS icons are licensed under a custom Apache 2.0 license, so the icon set is not covered by the same terms as the rest of the library. If your legal review cares about the provenance of assets, that is the line to point at, and it is worth reading the linked licence rather than assuming MIT covers everything in the package. On upgrades, the repository ships a codemods directory and a v7 migration guide, which together indicate that major versions involve real API movement. The codemods handle the mechanical renames; the migration guide is what you read for the parts that need a decision. There is no documented rollback procedure in the README, so a version pin plus a lockfile is the practical safety net rather than anything the project provides.

Editorial conclusion

Adopt Evergreen if you are building an enterprise-style React interface and want components that render correctly on the first try, with theming and server-side rendering handled by the library rather than by you. Do not adopt it if you need frequent releases, a large third-party ecosystem, or a component set outside the enterprise dashboard vocabulary; the release history shows v7.1.9 in June 2023, and the last push to the repository was on 2026-06-25, so verify the current state of the master branch and the open discussions before you commit. Before writing any code, check the v7 migration guide against whatever version your project already depends on, because the codemods directory exists precisely because that upgrade is not a no-op.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. segmentio/evergreen on GitHub