Piece of art

This is my semi-regular encouragement to read the docs straight through. No one does it and it'll give you a massive advantage. You don't even have to remember everything! Having a broad understanding will help you dive deep on specifics as needed.

As a fan of @storybookjs it is very tedious to wait for it to start. This is how I went from over 1 minute to less than 3 seconds to preview my @storybookjs in development. With the new performance wave coming from @bunjavascript I decided to upgrade my tooling, but I was unsuccessful in adopting Bun for a myriad of incompatibility. Asked around, everybody recommended giving @vite_js a try as a more mature alternative to Bun but still miles ahead of Webpack. This is where I started, 1.05 minutes, sometimes it was almost 2 minutes, this is my baseline to improve. I'm not very versed in Webpack, so there are probably many things to do, but my Webpack and Storybook Config were BLOATED and had a lot of repetition as I had to override many plugins. Not even gonna bother showing the config it was insane and huge. After learning the basics of @vite_js, and getting it running, I ended up with this config: It is tiny! The essentials sass modules plugin, that's already a win. ---- Storybook 7.4.2 for react-vite started 983 ms for manager and 25 s for preview --- It felt faster, 1/4th of the time it took Webpack but it was not enough. I still thought there was more to do; "vite serve" was instant; why wouldn't @storybookjs if I just have a few stories? Launching the app is monumentally more complex. After a while of reading performance issues in @storybookjs GitHub, I ended up tweaking the typescript config: It worked like magic! I ended up with 2.4-3.5s time-to-preview!!1! It makes total sense, @vite_js doesn't check TypeScript either, as it would hit performance. Honestly, it feels right, @code tsc on git hooks is enough to prevent pushing a type error or maybe running another process watching for tsc. I realised I do not want to pay the price of checking ts when launching anything. It is there to help me ship fewer bugs but should not prevent rendering or running anything, that should always be a different step otherwise it removes the magic of interpreted languages. That said, time-to-interaction is still greater than 3s (same with Webpack); When I navigate to Storybook, it takes a while until I see anything, a step to take another day; Ultimately I'm glad I understand a bit better @vitejs and @storybookjs to go from 1min to 3s time-to-previw, I went and applied the typescript config improvements to the Webpack config and just gained 5s, compared to 12s using Vite, whatever is happening under the hood, runs smoother with @vite_js. Thank you so much for reading my story ✨ hope it helps you in some way 🤝