[mm263]

The Storybook use case and the MSW use case is fairly similar to me: develop your SPA in separation from the backend and this is how Storybook was pitched to me and is usually pitched. Both allow me to hook up the backend after a component has been developed.

> 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.

[unleashit]

Thanks for the explanation, but I still don't understand how MSW and Storybook are comparable. As you said, MSW can be used to isolate a "backend". But Storybook really mainly to isolate the "frontend" parts. I see the point of both. On that note, while pretty happy with my current mocking solutions I've been meaning to take a closer look at MSW!

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.

[codethief]

> which did require a little wiring up to update the args

> 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.