Storybook is the most popular tool for developing UI components. The open source project has grown to over 450 contributors, 26k GitHub stars, and 1M npm downloads/month. It’s now used by teams at Dropbox, Slack, Airbnb, Squarespace and many more. Furthermore, we just announced that Storybook has full-time maintenance.

Common QuestionsWhy should you consider Storybook?
Storybook helps you develop components in isolation. This is handy because it enables you to mock hard-to-reach states and edge cases while developing the component. In practice, you end up building durable components much faster.

Up until very recently, we are all volunteers, and most of us still are. We take time out of our lives to make sure Storybook works as intended.

Sometimes on GitHub issues, we get requests demanding that a bug be fixed and not ignored or put off until a later date. We mean no harm and many times we do need to prioritize other things over fixing a bug for an edge case. As always, pull requests are welcome.

I've been pretty lucky so far I think. I haven't come across 'the worst' I think.

I've been really happy with it all. I sometimes take breaks, and I know I can because there are other maintainers besides me, we all help each other!

The hardest are the big features and changes, the ones that will be breaking people's setup of disrupt their workflow... We don't want to do any harm, but also don't want to end up with a over-complex codebase with tons of backwards compatibility and hacks.

Mistakes are made and they have to be corrected in software.

The hard part in any software is the clear and friendly communication between humans.

For me, I hate the guilty feeling when a community member does a lot of work on a contribution and I don't have the bandwidth to turn it around right away. Here's a recent example of a contribution that needs feedback from the community, a partial rewrite of the React Native storybook that shows addons on the device:

I remember trying to use storybook in the past, but ran into an issue with installing it because my company's computer has their npm configuration to point to Nexus rather than the public npm repository (I vaguely remember having an issue with how one of the packages were named even after changing a locally scoped npmrc file, but I don't recall if I got to the bottom of what was causing it).

However, I just tried installing it again and now it works ¯\(ツ)/¯ I'm excited to finally get to play around with it, but my lack of experience means I will have to come up with a lame, sort of generic, question on the spot.

What's the one thing you've worked on regarding this tool that you're most proud of? It could be a feature, UI decision, algorithm, anything really!

For me the feature I am proud of is still WIP. It is functionality to display addons in react native app itself instead of depending on the browser. I really hope it kicks of RN part move forward. Since this will allow to more easily use RN Storybook as a UI lib/playground that not only developers but designers/product people can use too.

There more things that need attention in RN Storybook. Better documentation, better ui, story hierarchy, more addons, creating screenshot testing. Also currently RN part of storybook is more or less done without testing, so we have a gap to fill. If more people will be attracted to RN part these things will be implemented a lot faster.

I think a big part of why Storybook is so successful is because of community.

I've definitely done more things on the community side of things rather than the coding part. When I joined in on the Storybook efforts, there weren't really anyone to answer questions, verify bug reports, and deal with the sheer amount of GitHub issues that we get. I started answering as many questions as I know the answers to and fixed bugs when appropriate or urgent. It goes a long way to understanding real user problems and also show users that we actually do care.

Thanks for all your work on this OSS product. A couple of questions...

Is Arunoda still working on Storybook, or is he full-time at Zeit?

I'm curious if you'd be considering creating other default setups for Storybook?

There's Vue, React and Angular. Would you consider something like Preact? I've done it by installing the React Storybook then just adding the preact-compats, and it works pretty well, but maybe for new comers, it could help them out if they show an interest in using Preact.

Also, we use Storybook at work with TypeScript/React and we've used the custom webpack.config to get things working to our liking. I wonder as well in a scenario like this, would you consider a default setup for say TypeScript/React or TypeScript/Angular?

A big advantage to Storybook is that we support many different frameworks and configurations. It is also a lot of work and time to develop, test, and support the full customization of every configuration possible on every platform.

We've definitely discussed this and the solution is perhaps allow some less popular combinations of frameworks and configurations to owned and maintained by the community. There are some work we have to do to modularize these configs to enable this.

Arunoda is full-time at Zeit, but he's still a project VIP and has the most commits of any human involved in the project (and I don't think any of us are going to catch up with dependencies.io at this point):

Not sure if you would call it interesting, but at Wave storybook has made it really easy for designers who code to collaborate with engineers. By working in storybook they don't need to get a whole environment running (20+ docker container, etc). It also helps to promote separation of concerns by giving the immediate, tactile benefit of easily being able to work on UI components in storybook.

Perfect answer. Storybook opens up the UI development process to a broader range of collaborators. Have seen lots of teams using it to do review and signoff, not just development. We plan to explore this a lot more in future iterations of the project!

+1 This is what we do at Chroma too. I find that it helps scale the amount of complexity a designer or dev is faced with at a given time. That makes in turn makes it much more straightforward to build UI components.

+1 For sure — we do this at Enok as well. Our team collaborates with a lot of startups + mid-size companies that need to maintain large repositories of components, and Storybook has been the best "component library browser" we've used.

Right now we're exploring integrations with React Storybook + Sketch and other product design tools. Really want to tighten up Design System automation + component reuse. Might do a blog post about those results soon.

Storybook's "stories" are pretty general-purpose, and I like to see people overloading it with whatever they find useful. A lot of Storybooks jam a styleguide into a set of stories, for example Lonely Planet's storybook:

I've also done weirder stuff, like use Storybook to document a web scraper on an internal project. Have not seen other people doing stuff like this in the wild yet, but expect to see more weird stuff as the tool gets more popular.

Have you got any recommendations / example use case of using Storybook to create a single source of truth for same components in multiple language stacks (eg. React and Rails ERB or React and plain HTML)?

The current version of Storybook only supports one view layer at a time. So we have @storybook/react @storybook/vue @storybook/angular etc. Norbert prototyped a next-generation architecture that supports multiple view layers at once, so this may get a lot easier in the near future, but it's a pretty big change so we're taking our time to do it right.

Fortunately Storybook is about making UI development easier, so we have Storybooks for our internal components and get a lot of testing "for free" using this setup. We should document our setup better to help other OSS projects move faster and with more confidence!

I feel like customization winds up being more important in OSS because there's a shared sense of ownership, and the bugs introduced by customization hiccups are easier to deal with via the community. But definitely agree, that design help can be the hardest to come by. I find people (politely) don't want to intrude in this arena sometimes, or don't know if they have permission.

Definitely following the project for cues. It's very clear that design is part of what you do well though!!

And very recently 2 of the maintainers of storybook have decided to join a start-up which is Storybook focussed and start work on storybook full time!
Truly the next chapter of the storybook epic:medium.com/storybookjs/storybook-t...

I think there are a few scenarios where people experience frustrations with Storybook

New to Storybook:

Setup: Getting started can get quite complex when it comes to webpack and babel config, especially for users who have components in an existing codebase. Adding support for things like LESS, TypeScript, etc. can be pretty complicated to someone who isn't familiar with frontend build systems. We've been discussing ways to mitigate this, through better documentation, presets, etc.

Advanced users:

Documentation - Storybook has been designed as a development environment first and a playground second. I've been experiencing an increasing need for Storybook to play the role of documentation as well. It makes a lot of sense to keep documentation and code as close as possible, and using Storybook to do this has been a point of discussion during our roadmap meeting for a while.

Customization - We recognize the need to customize the Storybook layout, theme, and everything in between. Storybook can be a branding or component playground for many organizations, and it makes a lot of sense for the rest of the Storybook interface to have the same feel and experience. The theme feature coming in 4.0 is a good first step towards that.

One pitfall I hear about is that people think you need to start using storybook right from the start.
That's not true, it's very much possible to start using storybook long after the start of your project, and gradually start using it for new components.

Then apply boy-scout rule and whenever you solve an issue in an components write a component-story for it, so it becomes visible / reviewable.

I've downloaded a few open source storybook repos from other companies, and worked on storybook repo at mid-size companies. They seem to all have the same problem of keeping start-up and HMR (Hot Module Reloading) time down. Any work planning to increase the performance of storybook applications?

It seems like scale is an avenue where storybook has more opportunity to grow! Especially if you're interested in loading components from multiple frameworks into one Storybook application.

Are there plans to have any automation in building stories similar to Styleguidist? I really want to use Storybook but given the size of the project I recently jumped into it really seems like a sizable effort would need to be made to get going...

We definitely rely on the community to support Angular, Vue, etc. and this will still be our policy going forward.

In terms of the engineering efforts, we've extracted all the shared code into their own separate packages. We have at least one person on the maintainers list who is well versed in the framework and can contribute or review pull requests.

I think the exciting thing about Storybook is that it doesn't really replace any one thing.

As frontend architecture gets more and more complicated and modularized, there has been a need to develop components independently and perhaps publish and demo as a reusable NPM package.

Component package maintainers previously had to spend time to setup their own development environment, mess with webpack, and structure the app to display different components in a meaningful way. They then have to figure out a way to create a static build to create a demo.

Storybook is able to provide all those features without starting from scratch, saving developers time and effort.

For Wave, we have many important components that are only visible in the middle of a process that is short lived and time consuming to reproduce (i.e. a loading screen that only shows while a user is having their payment account setup). Before storybook, we didn't have a good way to work on these components and were forced to temporary hacks in order to make them visible. Now, with storybook we have an isolated place to easily work on them, which has the bonus feature of being easily accessible for designers and PMs. It also makes it really easy for us to show of these states in sprint demos.

One of the future ideas I have is to integrate storybook with detox (e2e testing for React Native). It would allow to create screenshot testing or do even more complex things for the stories. I already had a small POC, I will continue to work on it some time in the future.

We have an open collective to support the project, and are getting donations from a bunch of big users like Airbnb, Facebook OSS, Xebia, Tipe, and Algolia, as well as from commercial tools built on top of Storybook like Chromatic, Percy, and Applitools:

Frontend interfaces have gotten more and more complex and so has the need for systems and architecture within the frontend. Many companies have large teams of 50+ people working on a single frontend system and that creates a lot of communication, management, and architectural challenges. This means that frontend developers on larger projects focus on very specific issues like build systems and webpack, performance, tooling, etc.

One thing that came out of this focus is a recent trend of companies discussing "Design Systems" and creating custom tooling around the shared Design <-> Engineering standards as a single source of truth. What a component is to an engineer may be totally different from what a designer thinks it is. In Sketch, it is easy to drag and drop a component, place it inside another component, and imagine that it works. But on the engineering side, these seemingly small changes can create lots of unnecessary work that can be prevented if the designer understands the engineering constraints. Communicating those constraints is hard.

I don't know what form of tooling or communication framework this will ultimately look like. Airbnb is working on importing React components into Sketch and creating drag and drop compilers to generate components on different platforms. InVision is creating a tool for designers to create branding and style guides with individual components. There are some pretty exciting developments in this area.

Storybook is really easy to adopt incrementally. You can add it to your project in 30 seconds, write stories for one component at a time, and get a feel for the benefits right away without having to invest a lot. Developers love it because because it's the best way to develop and test components in isolation. Designers love it because they can inspect live components without having to run an entire build on their local machine.

Thanks again Norbert and the whole team for taking the time to answer our questions today. Looking forward to helping add Preact to the CLI! Is there an issue for it in the repo, or should I create one?

Hey Norbert / Shilman! First of all, thank you for all the work that y'all are doing on Storybook!

I'm curious if it's possible to restyle or customize the storybook UI? I know you were working on being able to theme storybook, but what about additional customizations? Being able to add logos etc. I'm hoping to open source / make my storybook publicly available, but my company is asking me to make it more "on brand."

Hey Josh! Late to the game but we've merged the theming PR into the master branch, so you can customize a lot better now than you could before. This is available in the latest 4.0-alpha. The feature needs more documentation, but there are theming examples in the official-storybook example:

Norbert is starting work on a docs view for Storybook that will allow people to integrate stories more tightly with the rest of their documentation. This is going to change how people use Storybook--not just for component development and testing but also for showing them off beautifully!

I'm also really psyched about this change for Storybook for React Native:

It's a big departure for the project, since currently all of the web view layers share a lot of the same infrastructure, and this pulls RN even further out of the fold. But it's what a lot of RN users (at Artsy, Reactotron, Wix, Squarespace?) are doing anyway, so I think it will be really cool once we figure out how to get it integrated cleanly.

Typescript seems to be more popular and so from a community / onboarding perspective I think it makes more sense. I've used Flow in the past and it helped a lot, but there was also a cost associated with maintaining it.

My recommendation would be to try to to keep the complexity as low as possible. I think static typing can help deal with high complexity but at the same time it introduced some. So only you can decide if the trade-off makes sense for you, your team and the project.