storybook: a renderer-per-framework workshop, built on the next branch

One workshop, many renderers, no single framework

Storybook's central idea is isolation. It presents itself as a frontend workshop for building UI components and pages in isolation, and the README says teams use it for UI development, testing, and documentation. What makes it wide rather than deep is the renderer table: React, Angular, Vue 3, Web components, HTML, Ember, Svelte, Preact, and Qwik, plus React Native and a native package for Android, iOS, and Flutter. Consequence for the reader: the same tool covers many frameworks, but each renderer is a separate piece of the project, so a team on two frameworks maintains two integrations rather than one. Several renderers live in their own repositories: React Native, Qwik, SolidJS, and native, which is worth knowing before you assume a missing row is an oversight.

Addons turn the static view into a test surface

A Storybook on its own is a gallery. The addons are what make it a workshop. The README's addon table starts with a11y, which tests components for user accessibility inside Storybook, actions, which logs actions as users interact with components in the Storybook UI, and backgrounds, which lets a user choose backgrounds in that same UI, and continues through cssresources and others. The README frames these as covering component design, documentation, testing, and interactivity, and says the API lets you configure and extend in various ways. Consequence for the reader: the value of the tool is the addon set rather than the gallery.

The default branch is named next, not main

A detail that changes how you should install this is the default branch. The repository's default branch is next, and the README points out that there are two README files, one for main and one for next, telling you which version of the documentation you are reading. The recent releases mix both lines. v11.0.0-alpha.9 shipped on 2026-11-02, alongside v10.6.5 on 2026-10-27 and v10.6.4 on 2026-10-26. Consequence for the reader: the branch you land on and the docs you read are not necessarily the branch you will run. Because the default is next, a reader who follows the repository's default without checking a tag may get the in-progress line, and the presence of a v11 alpha alongside a v10 point release is a signal to pin deliberately rather than float.

The README never gives you an install command

Worth knowing before you start: the Getting Started section of this README does not contain a command to run. The Getting Started section sends you to Storybook's website, the documentation is on its docs site, and examples are shown through a Component Encyclopedia and through storybook.new, which creates an example project in StackBlitz. Consequence for the reader: unlike most tools whose README opens with a copy-pasteable install, Storybook expects you to leave its README for its documentation site, and the path from there depends on your framework and build tool. If you want a single command to try, the README's own suggestion is the StackBlitz example rather than a terminal install.

A monorepo of workspaces orchestrated by nx and vitest

What contributors face is a large Yarn and nx workspace. The root package.json is @storybook/root, marked private, and its workspaces span agent-eval, code and many code subpaths like code/core, code/addons, code/builders, code/frameworks, code/lib, code/presets, and code/renderers, plus scripts. The scripts lean on nx for task running, vitest for the tests with an explicit Node memory option, oxfmt and oxlint for format and lint, and husky for git hooks, and a bunfig.toml sits alongside the Yarn config. Consequence for the reader: running Storybook from source is a monorepo build, not a single-package install, and the ecosystem test scripts in package.json are wired to specific templates such as react-vite/default-ts and svelte-kit/skeleton-ts.

The changelogs are split by major version

The repository root keeps separate changelog files rather than one history. There is a CHANGELOG.md, a CHANGELOG.prerelease.md, a CHANGELOG.v1-5.md, and a CHANGELOG.v6.md, alongside a MIGRATION.md, a RESOLUTIONS.md, a MAINTAINERS.md, and a CODEOWNERS. Consequence for the reader: the split signals that this project has crossed several major versions with real migration steps between them, so upgrading across a major boundary is a documented project rather than a version bump, and MIGRATION.md is where the cost of that jump is written down. The presence of a prerelease changelog kept separately from the stable one also means alpha and stable notes are not interleaved, which helps when you are deciding how far the alpha line has drifted from the v10 line you are on.

The documentation defers to code examples and a hosted showcase

The README leans on external surfaces rather than restating anything. It points to the docs site for documentation, to a Component Encyclopedia at a showcase URL to see how leading teams use Storybook, and to storybook.new to spin up an example in StackBlitz. It also has a Discord link, a community page, and directs help requests to the repository's GitHub Discussions under a help category. Consequence for the reader: the Getting Started section gives no framework setup steps or config file names, so a reader planning an integration is expected to move to the docs site, and the StackBlitz route is the fastest way to see a working Storybook without touching a local project.

Editorial conclusion

Storybook fits a team with several frontends that keeps re-implementing the same button, because it gives them a single place to be developed, tested and documented in isolation, and it earns its cost through the a11y and actions addons. It does not fit a team that needs a stable install, because the default branch is next and the recent release list mixes a v11.0.0 alpha line with v10.6 releases, so what you get depends on which branch or tag you pin. Before you adopt it, decide whether you track a tagged release or the default branch, check that your framework has a renderer in the supported list, and read how the addons you rely on are configured rather than assuming they behave the same across every renderer.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes