Ponder and better educate on the displayed metrics

[sarahdayan]

Hey there!

First of all, thank you so much for Bundlephobia. I use it often, and it's an excellent contribution to the JavaScript community. And because it has become so prevalent and used in high-reach tools, I think there are opportunities for improvement to further fulfill its role of educating and informing users.

Distinguishing between all build formats

Right now, the result page for a package shows the bundle size of what's listed as the main module. This doesn't always reflect what users would end up using in their projects.

For example, someone using Vue.js in a Webpack 2+ or Vite-powered project will import the ESM build (listed under module), while someone importing it from jsDelivr will import the UMD build (listed under jsdelivr). The CommonJS build (listed under main) is only useful for older bundlers such as Browserify and Webpack 1, so it's hardly representative of any actual usage.

Suggested solutions

• Bundlephobia could display the bundle size of all available modules (maybe within a reasonable set for the modern age, such as UMD, ESM and CJS), not just the main one.
• Bundlephobia users could be presented with a way to select the type of build format they want to see the size of.
• Bundlephobia could educate more on what each build represents. Not everyone is aware of what the difference is between all available JavaScript formats, so instead of just saying "UMD/ESM/CJS", Bundlephobia could add notes like "UMD—If you're planning to use this library with a <script> tag, without a build step", "CJS—If you're using this with Node.js or with older module bundlers", etc.

Emphasize tree-shakeability

When a package is both exported as an ECMAScript module and is marked as side-effect free, Bundlephobia displays it and provides a useful Exports Analysis section that shows the breakdown of each individual module. This information is crucial, because such packages usually heavily promote modularity—that is, you rarely use the whole thing, and your bundle size will be dramatically impacted by this. Unfortunately, the result page doesn't emphasize it enough.

A good example are date-fns and dayjs. The whole date-fns package weights 19.3 KB minified + gzipped, but it's entirely modular and designed to be used that way. Most of its functions don't exceed half a kilobyte. In contrast, dayjs is 2.8 KB minified + gzipped, but it isn't modular (it does have concerns split into plugins, but it's not as atomic). So on paper, dayjs is smaller than date-fns, but in reality, dayjs will always cost you at least 2.8 KB while date-fns will cost you just what you consume, which might very well be a lot smaller. Yet, Bundlephobia shows dayjsas a 86% smaller alternative to date-fns. This is misleading because it doesn't at all take into account how both projects are architected, yet provides a number that may direct users to a solution that might not be in their best interest.

Suggested solutions

• Bundlephobia could make it clearer that a project is modular and emphasize it so that users recognize such patterns as beneficial.
• Bundlephobia could tone down the "xxx% smaller" indication when at least one of the projects is modular.

Provide educative content

Not everyone is familiar with certain terms such as "tree-shakeable" or "side-effect free", and these pieces of information are discreet on the result page while the full bundle size is highly visible. Since Bundlephobia is about finding the cost of adding an npm package to one's bundle, with today's JavaScript tooling, it seems crucial to emphasize and educate on such features which are among the most important aspects that a user should consider.

Suggested solutions

• Bundlephobia could provide definitions for terms like "tree-shakeable" and "side-effect free" so that users who don't know what it is can immediately understand the benefits.
• Bundlephobia could provide additional information about how to interpret the full build sizes.
• Bundlephobia could provide additional bundle sizes at the same level when a project is modular—for example, modular packages could display average size per function.

Afterword

Please be assured that I'm not shooting at Bundlephobia, only providing constructive criticism and possible solutions because I think it's a great project that could be even better. I'm also down to participate in finding and implementing the solutions, as I'm well aware that everyone is doing that on their own time.

Looking forward to discussing this all further!