Comparison to storybook-for-vite ?

[redbar0n]

https://storybook.js.org/blog/storybook-for-vite/

I'm thinking especially given your recent upcominig beta release roadmap.

Given your realignment to Vitebook's original goal:

We're probably going to take a different approach to the Storybook stuff moving forward, but due to financial/time constraints, it'll have to come closer to 1.0. Let's first focus on an amazing core for building and deploying sites/docs first.

and in line with your desire to conservation of your resources/time, then perhaps Storybook for Vite could be complimentary to Vitebook?

Or would Vitebook as a Storybook replacement offer something completely unique (besides running on Vite) that Storybook for Vite doesn't accomplish?

[mihar-22]

and in line with your desire to conservation of your resources/time, then perhaps Storybook for Vite could be complimentary to Vitebook?

It definitely could be. I'm not 100% certain how we'll bake in Storybook support. If the integration story for the official Storybook plugins and Vite ecosystem is smooth then maybe we go that way.

Or would Vitebook as a Storybook replacement offer something completely unique (besides running on Vite) that Storybook for Vite doesn't accomplish?

I think the main concern with Storybook is that it's a hassle to setup, and it's package install size + client-side is bloated and occasionally laggy. There's other concerns as well around such as it only supports CSF format which isn't ideal in SFC-based languages such as Vue/Svelte.

I believe most people would love something lightweight that just works out of the box and handles their minimum needs when building/testing UI components. We might opt for a lightweight path. A recent library development in the Vite ecosystem called whyframe may have given us the opportunity to easily bake in a simple Storybook-like environment.

As I said earlier I don't actually know yet and this will require much more discussion after we roll the Beta out. If you have thoughts on this matter then feel free to share, love to listen :)

[redbar0n]

Thanks for the candid answer. :)

When we're on lightweight Storybook alternatives, here is another one I've noted:

• react-cosmos is a lightweight alternative to Storybook BUT does it work with Vite/Rollup (?)
  • react-cosmos vs. storybook

Personally, I think I'm going to hold off on Storybook. Since it seems generally disfavored among thought leaders in the community these days:

• flybayer of BlitzJS
• Theo of create-t3-app + Peter of RedwoodJS
• Theo rant
• On the Tamagui discord

For various reasons: the ones you mentioned, plus “I would only view my components in isolation if I was building a ui library”, “Or the project has a bigger dev team, but even then I don't feel like it provides that much value”.

My impression is that Hot-Module-Replacement (HMR with Vite) / Fast Refresh replaces the need for developing components in isolation, because you can always see them in their realistic context, which seems more effective and better for UX. Even though having a showroom such as Storybook would be neat for the off change I'd need to showcase something. Correct me if I'm wrong.

[mihar-22]

Personally, I think I'm going to hold off on Storybook.

I'm on the same boat personally and the only time I tried using Storybook seriously it ended up in balls of flame. I spent so much time managing it that nothing valuable was achieved. I wouldn't recommend unless building a design system or UI library. I think the fact that larger companies use it makes others think they need too as well which is far from the truth. Large companies most likely have a design system they're managing across multiple teams where it makes perfect sense to use Storybook.

Since it seems generally disfavored among thought leaders in the community these days:

Thanks heaps for sharing those links, I checked them all out and have to say I 100% agree with everything I heard. Even when I worked at a larger company it carried no weight since QA would never really use Storybook to test app-level concerns. It's always best to test everything in context.

My impression is that Hot-Module-Replacement HMR with Vite replaces the need for developing components in isolation

Agreed! Hard not to agree that everything in context is always better. There's some meme about unit testing and this that makes me laugh but can't find it.

All I know right now is that if we include Storybook-like stuff it would be lightweight enough that it's fine to bundle as-is, otherwise it would have to be optional. No need to add something bloated that 90% of people don't need. Always open to changing my mind.

[IanVS]

Hi, I'm one of the maintainers of the Vite builder for Storybook. This is an interesting discussion, and I think it's worth having. It seems I have a very different experience from that of some others when using Storybook. I began working for a greenfield startup last year as the first front-end dev. I chose to build the app in Vite, and to use Storybook to help in the development. I appreciate having an isolated environment to build components for a few reasons:

• I can break down a design into pieces and start building the small parts first. It encourages me to think about which components might be reusable, or how I could create the component in a way that will be flexible enough to use in other parts of the app. I can start building these small parts immediately, without having to build the page or containers first.
• Similararly, when building in isolation, I tend to think more about the component's API than I would if I were building it for just one specific use. Rather than hard-coding the values I need for that particular page, I step back and consider which abstractions make the most sense. Likewise, I don't end up in trouble because I gave my component a particular padding or margin to make it fit in the page, and it's clear that it's up to the container/layout components or page itself to handle spacing between components.
• Because I'm thinking about the different states of the component and can easily put the component into those states through a set of stories, I can almost "TDD" my components. I start off by creating a story for a certain state, I work on the component until it looks/works like I want, then I move to a different state.

So yeah, I like building in isolation from the app. I even build groups of components and full pages in storybook, since it's easy for me to mock out the data and experiment with different situations. This is also nice to have for sharing the PR with the single other front-end developer in my company, and our designer. They can see that I've thought of different edge cases just by looking at the stories, rather than having to contort the app into every possible case. I don't use Storybook as a traditional "Design System" though. I don't have a ton of documentation (only some docblocks from the code that it pulls in), zero MDX stories, and nothing super-fancy overall.

But, the biggest reason I use storybook is for the simple testing I can do. I mostly use two types of tests: visual snapshots and interaction tests.

1. Visual snapshots. I use Chromatic to take snapshots of my components, groups of components (like forms), and even pages. This has been super valuable in catching visual regressions. There have already been a handful of times where I pushed a change in a PR that accidentally broke styles in a different component or page. And, I've been able to make large refactors / re-stylings with confidence knowing that there aren't a bunch of crusty corners of my app that I forget about which are being broken. That's awesome peace of mind.

2. Interaction tests. I use the "play" function to trigger user interactions in my stories to either set the component up for a visual snapshot or to make assertions that it's behaving the way I want. It's so much easier to write tests when you can see the component in the browser and not having to debug jsdom or decipher the state of the component based on a dump from the DOM. I can step through the test and see easily where it's going wrong, and I can run all of these tests in CI.

So, I disagree heartily that Storybook is only for big companies. My entire frontend team is me and one other dev, plus a designer. We've been building an app for about 1.5 years, and so far we have 740 stories for 163 components. The rest of the product team is impressed with how quickly we can build UIs, and I think in that entire time we have only shipped one or two small UI bugs.

I think there are definitely some valid criticisms of Storybook, and the Storybook team is taking them seriously. For instance, Storybook has had a history of being a bit "bloated," but in a recent alpha of 7.0, I checked the install size of Storybook compared to the stable 6.5, and it was 44% smaller in node_modules. And now, the Storybook UI is pre-bundled with esbuild, which means for vite projects, webpack is not installed at all. I'm still in the process of cleaning up some other dependencies, so I expect the file size to drop still further. And for folks who have had a tough time configuring the vite builder, in 7.0 we will now automatically read and extend from the app's vite config file, so it should be much easier to get up and running. There is also improved support for svelte-native story files, though that's still a work-in-progress.

So yeah, there are a bunch of features of Storybook that I don't personally find that compelling ('m not at a huge company), and there have been times where storybook took forever to start or update (when I was using weback back in the day), but things are getting better, and we're listening to the Vite community and want to build an excellent tool for everyone.

[mihar-22]

Wow, thanks for that detailed response and shedding more prespective on this @IanVS! I'm short on time so I can't go crazy in detail but I wanted to cover some of the high-level arguments:

Similararly, when building in isolation, I tend to think more about the component's API than I would if I were building it for just one specific use.

Agreed. This is similar to when you open-source some tool and probably one of the biggest arguments in favour of Storybook outside of testing. Important to note that it's not something you need Storybook to do. If you build a healthy habit of simply thinking deeply about components, their API, their relationships, and having a review process then you can achieve the same results. Storybook can definitely help you get to a better place or even prevent poor decisions occurring outside of your control when working in a team. Everything is iterative regardless of whether Storybook exists or not as new information is made available at some point in the future which you don't have yet. Incremental improvements end up going much further than trying to perfect things all at once.

An interesting counter-argument might be that because Storybook "forces" you to build components in isolation it might inadvertently introduce scope creep in the form of over-engineering components.

But, the biggest reason I use storybook is for the simple testing I can do. I mostly use two types of tests: visual snapshots and interaction tests.

I haven't had experience going that far with Storybook but I usually achieve those same goals with other tools like Cypress. I feel if you're investing that heavily into testing then just go all the way with a more comprehensive testing tool? Cypress still enables you to see these interaction flows in the browsers, replay them, save snapshots, and also provides a video recording when they fail.

I'd rather test these components fully-integrated (app-level) rather than in isolation. If you can't reach a particular UI state in your app than there's no point of that state existing in isolation. I think testing in isolation is cool in concept, but it doesn't really make sense to me unless you're building a UI library or design system where it's being used across any number of applications.

So, I disagree heartily that Storybook is only for big companies.

I definitely don't think Storybook is just for larger companies. I'm just advocating that people don't feel the pressure to adopt something because others are. Similarly to other forms of higher-level testing such as integration and E2E, I'd advise adopt based on your individual, team, and project requirements.

I think for individuals who are working on a single application it's hard to make a good argument that you should or have to adopt Storybook. The value add in exchange for maintanence overhead is probably never worth it. This argument could also be made with many forms of testing. Probably best considered on case-by-case situation or after UI issues start becoming a clear problem. Investing too early in some tools isn't particularly a good thing, short-term vs. long-term trade offs.

In your case, Storybook makes sense to me as you're working in a team which also includes other non-dev stakeholders (i.e., designers). I'm happy your team has found their rhythm and the investment paid off :)

Things are getting better, and we're listening to the Vite community and want to build an excellent tool for everyone.

I've always appreciated how hard the Storybook teams work on improving the tool and integrating it in the ecosystem. One of my absolute favourite OSS teams hands down. I personally haven't tried Storybook in a while so I'll definitely be giving it a shot again before considering whether it's a good fit for Vitebook or not.

Also, thank you @IanVS for all the amazing work you've been doing on bringing Storybook and Vite together. It's truly appreciated.

[IanVS]

Thanks for the discussion, you make some great points, and I agree with much of what you're saying. I think the decision to use or not use a tool depends on a lot of factors, not least of which are the team (both their experience level and the composition of devs and other stakeholders) and the product being built.

And yes, of course as you get better at building components and applications, it's not as critical to build them isolated from the app. I don't mean to imply that good components can't be written outside of a workshop, by any means. It just helps devs fall into the pit of success, I think. But it's not a silver bullet, and can lead to over-abstraction if you're not careful, as you say.

Regarding testing, I did try setting up Cypress at one time, but it didn't work well with our passwordless 2FA auth setup, and I found the syntax a bit clunky to use. I already had experience writing stories, and using @testing-library for component tests, and jest's expect assertions, so the interactive tests in Storybook were a natural fit. I use Vitest for unit tests of my non-component logic, Storybook for component tests, and Playwright for a handful of e2e tests whose only real purpose is to make sure interactions with the real API server are working correctly. I've found that this works well for me and my team, but like you said, everyone is different and has different goals and experiences.

I'm just advocating that people don't feel the pressure to adopt something because others are.

💯. I don't mean to say everyone should use Storybook. If they think it might fill a need I hope they give it a try and don't only listen to the negative voices out there, but everyone should make their own decisions based on their needs and judgement.

I think for individuals who are working on a single application it's hard to make a good argument that you should or have to adopt Storybook.

Absolutely. I always expected to have a team on my project, and maybe someday a fairly large one. If it was just me, or I was building a side project, I'm nearly certain I wouldn't spend the time on it. Just like I didn't worry about building a component library for our marketing site. Those are likely to change often, and normally aren't very complex to begin with.

It also helps that I have a designer who thinks in terms of components, and is willing to stick with those components that he's designed, rather than treating each new UI as a blank canvas. That makes a ton of difference. If I was having to throw away my components often due to redesigns, or only use them in one place, I likely wouldn't be using Storybook, or at least not as thoroughly.

I personally haven't tried Storybook in a while so I'll definitely be giving it a shot again before considering whether it's a good fit for Vitebook or not.

I do hope you give Storybook another shot, though maybe give us a couple more months to get 7.0 a bit more polished 😜. I'd also love to find ways for Storybook and Vitebook to work together, if you're willing. Don't hesitate to reach out to me in either the Storybook or Vite discord (I'm IanVS in both), if you'd like to discuss anything more "informally".