I have worked with storybook extensively over the past couple of years and my team is moving away from it in favour of MSW (https://mswjs.io).

For "4th page of a 10 page form" during the development there's hot reloading which is really stable nowadays and haven't failed me, although I understand that some setups are old and it might be easier to configure Storybook than good hot reloading.

I'm not entirely sure about the testing part of it and I'd be grateful if you could elaborate. I haven't felt the need for some special setup with SB because for unit tests, I can test a deeply nested component separately with react-testing-library. For E2E tests, I usually test the whole form anyway.

I agree on the component library part, this is probably the only use case where Storybook is 100% justified, but I'm unconvinced about the usual SPA use case

As far as live reload, you're right but only once you've achieved the state. If you're firing up storybook or moving between components, you can already have any state ready to go (or quickly set with the controls). If you're in the actual app and don't have something like Redux Dev Tools, you have to manually go through the steps.... which can be a pain.

That said, so far I'm only using Storybook for the "component library" use case. And for that it's a big improvement from the previous DIY app I had.

At first, I was confused by what OP meant, too, but I think the point is that if you can mock your data easily, then getting your app into the desired state is straightforward enough that Storybook becomes unnecessary. At least, that's how I interpreted it.

> the play feature beats E2E if you want to show a smooth demo for clients/fellow devs

We actually haven't used this at all, but it's a neat feature.

The tradeoffs we evaluated were:

- Storybook allows to develop components in isolation, but requires to structure your components in a very specific way that is detrimental to how React works (see my other comment with the Oxide in the thread).

- MSW allows to develop your whole app in isolation but it lacks all of the bells and whistles that Storybook has (e.g. testing, various plugins, demo, discoverability of the components).

But in general, our use case is developing an internal SPA using Tailwind, so we don't exactly have a component library that we need to develop in isolation. I can see the value of Storybook if that's the case for your team. Many other companies maintain their homegrown UI library that could benefit from all of the features of Storybook, so it makes sense for them.

How does SB require a certain component structure? I didn't have to touch mine. They have a "sub component" feature for documenting nested components that work together, although I didn't even use it. Just used either decorators or render functions in my stories where needed (which did require a little wiring up to update the args).

I don't use Tailwind (yuck, sorry!), but how is choice of styling a factor?

The auto docs have some weird glitches and did force me to adjust my TS types a bit is my complaint (and react-docgen-typescript wasn't working for me at all).

I agree that SB is probably not worth the effort for everyone though.

> The auto docs have some weird glitches and did force me to adjust my TS types a bit is my complaint

This, to me, is the biggest downside of Storybook. Storybook might provide reasonable defaults but if you want to configure how exactly things are supposed to look & behave, and want type support, you are in for a world of pain, arcane magic, and glitches. My team recently convinced me to give Storybook another shot in our current project and I regret it already and now remember again why I always disliked it. We are indeed developing a component library and in hindsight I would have preferred to write a simple Vue app showcasing our components, and adding any component controls myself.