[koboll]

After using Storybook for a couple years at work, I've soured on it. The Canvas / Docs distinction is weird and confusing. There are lots of poorly documented aspects (did you know pressing "S" causes the sidebar to disappear without any sort of visible way to open it again?). The controls are awkward to build complicated components around.

Consider just rolling your own component showcase. You can do it in a day and probably get a much cleaner and more straightforward static site out - all you really need is a sidebar and then display areas hooked up to buttons. That's it. Storybook is just a heavy, complicated, awkward set of abstraction layers over that very simple core experience.

[dimal]

My initial reaction to this was to think, “heresy!” SB has been amazing for developing components in isolation and setting up a design system. Then I thought it over. Yeah, the great thing is implementing a design system and developing components in isolation, not SB. And it’s not hard to set up a bespoke system to develop components in isolation. Setting up custom tooling in SB was possible, but was certainly made a lot harder by the fact that I had to jump through their hoops. And then I think about how many times they’ve changed the format for defining a component story over the years and I start to get annoyed. Yeah, next time around I might just roll my own.

Oh, and that “S” thing. Yeah, I hit that. Grr.

[felixfbecker]

Don't forget when you wanna upgrade Webpack but you can't because Storybook still only works with the old version months in

[roman-holovin]

>developing components in isolation

Nice "isolation" they have when they bundle in whole corejs into component view.

My component was parsing a lot of dates from RFC3339 string via `new Date` and it was mind-blowlingly slow. I opened dev tools and was greeted with javascript re-implemenation of the Date constructor in all glory.

Suffice to say that I had zero intentions to ship that into production bundle. Thanks Storybook, isolated playground indeed.

[lloydatkinson]

1000% this. It’s a nightmare and the maintainers have been less than receptive in the past. The fact it’s built on react which apparently means it needs a million react dependencies. Fair enough but when the dependencies break your eg Vue app because of the deeply flawed way NPM resolves dependencies and screws things up in mysterious and frustrating ways, it’s just a non starter.

Writing documentation for the components is a weird mix of JSX, interpolated strings, and markdown. Often overlapping, confusing, and conflicting ways of doing the same thing.

[Griffinsauce]

Same here but for other reasons: it just keeps breaking all. the. fucking. time.

Change anything about your webpack config? Good luck. Updating SB itself is also always a complete pain in the ass.

Worst of all, there are conflicts between its internal code and your app code. "isolated" is a lie, your components are webpacked along with theirs so if you use Emotion for styling for instance, suddenly you have a conflict in the style context.

Building a custom solution can be worth it depending on how many features you use.

[claviska]

This was my experience. I ended up using Docsify for my web component library (https://shoelace.style) as it renders markdown on the fly and works well with custom elements.

The idea behind Storybook is great, but it’s gotten slower and heavier over the years and it seems like the project has lost direction. Is it a component sandbox or a documentation website? IMO, it does neither of them well anymore. The UI is hard to customize, the shortcuts are annoying (pressing S while focused in an input toggles the sidebar, for example), and it takes forever to install and launch.

I moved on a few years ago and haven’t missed it.

[reidjs]

Thank you! My team was looking for a tool like this and storybook was the only one I knew about. I linked to it in slack as an option and the people delegated to implementing the component library hopped on board. After looking at how complex it was I knew it would be a terrible idea for what we needed: something very basic. I tried to veer them away from it. I even rolled my own component showcase like you were talking about before they put storybook in. No luck, they implemented storybook and after a couple months the people delegated to roll it out lost interest in it.

We still use it, because management doesn’t like the idea of how much time we’ve already sunk into it. Storybook is a nightmare to maintain and train devs on.

[Waterluvian]

If anyone needs to be able to not fall for the sunk cost fallacy, it’s management. That’s rather concerning.

[brundolf]

> Consider just rolling your own component showcase. You can do it in a day and probably get a much cleaner and more straightforward static site out - all you really need is a sidebar and then display areas hooked up to buttons.

It gets more complicated when you want to let people play with the component's props/parameters from within the GUI. I hand-rolled one of these once and was able to use a library that scraped prop info from our React PropTypes automatically and put it into a JSON file, but it was fiddly and eventually broke when we started using TypeScript. I don't know if something better exists now (or how Storybook solves this), but it's a hard problem. And it's not just about gathering metadata: you have to dynamically set aside a piece of state for each prop that hooks in accordingly. Sometimes, like with value/onChange, you need to hook two different props together into the same piece of state. Etc.

I suppose you could just hand-code all the controls for each component, but at that point it seems like it would be more trouble than it's worth (especially the ongoing maintenance burden every time one of the base components changes)

[nsonha]

How useful is the knob thingy anyway? The devs using this would be looking at the code anyway and all you need is to document your props properly and let hot reload takes care of it

[brundolf]

It's the main benefit IMO. It's great for quickly seeing what a component can do, but it's also fantastic for testing the different features. You can click through all the states (and transition between them), mix and match every permutation you can think of to make sure they all work together, etc. I've discovered several bugs this way in the past by selecting an odd combination of flags and finding out they break when used together.

Tbh without the ability to play with props I wouldn't even bother with a storybook-like interface. As you say, they probably have the code (and all its comments) in front of them, so what's the point of pretty documentation at that point?

[runarberg]

I’ve found that with semantic prop names + values and good documentation there is no real need for developers to play with the components. E.g. if you have a boolean property called `filled` on a button, and the mock has a filled button, a junior developer can easily figure out how to get the button to look according to the mock without any need to open the story book and play with the knobs.

The only benefits for the knobs I see is to provide a nice interface for the designers to scrutinize the system on an atomic level. However I am not a designer so I don’t know how valuable it is for them to do that through story book over exploring the actual app or a custom showcase. And if the benefits to the designers are only marginal, you have to ask if it is worth it for devs to maintain the storybook interface.

[brundolf]

When I used one we didn't have a designer at all, much less neatly-organized mockups.

But even if we had, we might not have discovered things like "oh, if you have the modal set to show a close button in the corner and also give it a really long title and make the window narrow then the button gets awkwardly pushed to the next line". The kind of stuff that mockups often don't cover, but real-world users might encounter some day.

[crubier]

I kind of agree because I had some pain points with storybook on a large legacy project with a lot of quirks. But on a fresh project where you don’t try to do fancy things, it’s perfect.

Actually storybook has become sort of a litmus test: If you need to hack storybook to death to make your fancy thing work, then it means that you will have trouble with other tools anyway (Jest, Cypress, some CI tool or some Browsers), so maybe reconsider it first.

So your mileage will vary. But on fresh modern project my advice would be: go for it (and use Chromatic as well in your CI, it is super cool!). If you have to use fancy stuff that make storybook too complicated then drop it.

It’s easy to drop, but not easy to insert in an existing project. But for me the storybook / chromatic Combo has a 10x ROI on a project in 2021.

[JusticeJuice]

The bit that really fucked me over was the fact storybook runs rolls it's own webpack instead of integrating into whatever your project has. Cause of this, my components were rendering differently in prod to storybook.

For frameworks with complex webpacks (e.g. gatsby) it's actually really hard to integrate well, particularly when you don't really want to get that deep into webpack itself.

[NaN1352]

I agree it’s fairly easy nowadays to maintain a "live" demo of your components with Vue or React.

It’s useful also to keep semi static mockups when you do revisions on a homepage for example (as the html/css guy) so you can preview something with the team.

And nowadays you have simple Markdown + Vue plugins for eg. Vite, so you could even write your styleguide / demo as .md files.

[nkozyra]

Agreed, I found it heavy weight, if a noble idea.

Isolated components that can be tested under different scenarios is a great idea, but I've found it uncovered almost no bugs and served almost exclusively as a showcase.

[roberttod]

Completely agree. I've seen Storybook used at 2 different companies now, and always found it confusing and the docs incomplete. Developers get excited about auto-generating docs but in the end it's nowhere near as good as just setting up a static page of rendered components with hand-written documentation alongside (as another sibling comment suggests).

[grativo]

When I first heard of storybook I was not able to understand what exactly it did. I feel like this is similar with a lot of cool technologies built. At least for beginners or potential users, it's hard to get an idea of what something does if it's not presented clearly. Maybe just for me though.

[type0]

It is such an over-engineered piece of crap that I regret spending so much time trying to use it. Use a templating language of your choice and some simple npm and Gulp scripts to build html and you'll be so much better off.

[gtm1260]

Hard agree. The overhead of fixing all the issues with the Storybook versions of components made a lot of people just skip it all together.

[wereHamster]

This is why I created timvir (https://timvir.vercel.app). It really doesn't take much more than a few custom components that you can compose in MDX files to create documentation pages. The timvir blocks are whatever I needed at that time, a lot of them are still experiments, others I use regularly. Since MDX, Timvir are just React in the end, I can even show, document, test interactive components. It's probably not as convenient as SB at this point though.

Since Timvir is basically just a component library and not a build tool on its own, integrating it is quite easy, and won't break whenever you upgrade Next.js, Webpack etc. That was one my my main motivations: tools that come with their own build system are hard to make, and even harder to make reliable. You are buying convenience in the short term, but getting pain in the long term.

[stevenpetryk]

Not to mention that every time you start Storybook, it seems to compile itself. At Aha! we use it for hosting our component library (which are web components written in Stencil, and which don't require webpack to be built), and even then, we spend about 20-30s waiting for webpack to startup and compile everything inside of Storybook.

[codethief]

Add to that that Storybook's TypeScript "support" doesn't actually rely on TSC. Instead, Storybook uses Babel to do the transpilation TS -> JS (meaning that types aren't actually checked; besides you run into weird bugs at times).

[ElFitz]

Personally, I found that working with clients where everyone, designers included, followed the principles laid out in atomic design[1] (or closely enough), not matter the tools used, and favoured reusing existing components, was much simpler and pleasant.

But it usually only went as far as having the designers follow it in Sketch, Figma or whatever, and the devs separately implementing the components themselves.

What is the (supposed) added value of something like Storybook over this?

[1]: https://bradfrost.com/blog/post/atomic-web-design/

[gedy]

> The Canvas / Docs distinction is weird and confusing.

Yes. While I otherwise like Storybook, the addition of docs along side canvas is not clear what the purpose is. Incremental way to introduce a new default? Very confusing to have both tabs available at same time.

[animanoir]

What do you recommend then?