Reconsider Using Storybook: Is It Worth the Hassle?

I have worked with Storybook across multiple projects over the last three years. I have even written about the benefits of using Storybook-Driven Development. However, after removing Storybook from our latest project, I began to feel that the costs of adopting Storybook outweigh the benefits.

An Effective Storybook Environment

The ideal Storybook environment is one in which developers, designers, and the client all collaborate on the Storybook files interactively. This means dedicating front-end developers to developing and maintaining UI components (and their associated story files) and designers who use the Storybook site for mockups and testing. It also requires clients who view the Storybook site to demo components and give additional feedback. If you’re missing any of these pieces or if any party has not bought in on using Storybook, then it’s likely to be a net drain on your team.

While Storybook offers support for several frameworks, support for projects other than React feels like an afterthought. This is quite notable when working on an Angular project, where some versions of Storybook would actually pull in React as a dependency into your “package.json”. This is obviously not ideal and creates dependency bloat.

Reconsidering Isolated Component Development

One of the main benefits of this development environment tool is being able to render and develop components in isolation. While this initially seems helpful, it is often unnecessary and can mask unexpected styling conflicts. With hot reloading, developing a component directly in the browser in the context of the rest of the page is just as convenient as developing it in the Storybook screen. Sometimes the component may actually look different when used in the full page, due to global styling or some other interaction. Therefore, seeing the component in context during development is more useful than developing it in isolation.

Furthermore, suppose you really want that component isolated (for instance maybe it is deep inside a modal, or in another hard-to-reach spot). In that case, it’s often simpler to create a temporary route and drop the component in. If you don’t care about the documentation aspect, then this will be sufficient to provide a similar developer experience, without having to also manage Storybook and the “.stories” files.

Maintenance Challenges

Storybook also creates extra maintenance for developers (or designers) who maintain the “.stories” files. Every time a new UI component is created, you will also be creating a Storybook file for it. Any input data on this component will need to be mocked out in the Storybook file. Whenever the API for that component changes, you will also need to update the associated Storybook files. In this way, this development tool serves as living documentation, at the cost of maintaining all those extra files. If your designers and clients are not even viewing these stories regularly, there’s little value added compared to the maintenance costs.

Is it worth it?

If you work on a project with dedicated frontend developers, designers, and clients who are all 100% bought in on using Storybook, then go ahead and use it. However, for the rest of us, you won’t get enough value from adopting it. After having ripped out or just abandoning Storybook on a few projects, I will be cautious about automatically reaching for it the next time.