alt Hacker NewsI'm not sure the author realises _what_ a massive impact bundle size has on the main thread though, especially hydration. The majority of apps I've optimised over the years have the (often vast) majority of main thread time spent on the bundle parse/hydration (plus obviously network).
Also, removing dependencies is not easy. I've seen many corporate that have a huge UI lib for example that everyone should use for brand consistency. But it's many MBs of JS, because it has to cover every possible use case.
This doesn't even get into 3rd party vendors who _also_ ship react et al and have other bundles.
I'm not saying the article is wrong, but if you want to free main thread time especially at the most critical point (when the user has initially loaded the page) you _probably_ will find that most of the opp is in bundle size and hydration improvements.
Replies
All good points. Perhaps rather than saying the fixes are straightforward, I should have said it's a straightforward concept to understand. If your app takes forever to load because of a huge bundle, you need to figure out how to make the bundle smaller, somehow. (How exactly to do that is where it gets complicated, like you say.)
I would think, or hope, a UI library like that could benefit from webpack and tree shaking such that only the needed components end up in the final bundle.