When developing websites you often need help to solve issues that would take a long time to do manually but are very easy to do with the proper tool at hand. This post lists some of those and what they are used for.

unpkg.com

When trying to search the web for an issue with a package it's often convenient to take a look at the actual code in the package to verify some assumption. Doing this in VSCode browsing through the many packages inside node_modules can be very cumbersome and unpractical. unpkg.com offers a simple solution by quickly listing the contained files for any npm package. Head to unpkg.com/react to see the entry file directly or adding a slash unpkg.com/react/ will list all the contents. The current version will be added to the url and can also be changed this way.

npmcharts.com

The popularity of a package can help to find or distinguish between packages. Similarly, changes in popularity can give certain hints about the general usefulness of a package.

This comparison between React, Next and Gatsby first-of-all shows the difference in popularity between react and it's server-side rendering frameworks. When react is removed from the comparison one can also see that next has made significant gains in popularity in the last year while gatsby is declining slightly. Declining package popularity is rare and usually indicates that a package garnered significant hype among developers but didn't get adopted into productive applications and the more broad mainstream. How well a package will suit you or your team can often be very subjective and depends on many other factors than just popularity. The enduring popularity of redux in this comparison with mobx,redux,immer is quite surprising as I wouldn't recommend redux to anyone anymore. Check out this post about the advantages of MobX in comparison with the redux approach to learn more about this specific choice and possible explanations. The popularity of immer might be explained by downloads made due to it being a dependency of a few other popular packages.

bundlephobia.com / bundle.js.org

Thanks to tree-shaking, lazy-loading and huge improvements in mobile connections the bundle size has become less of an issue. Still, for large websites with many common components the size can quickly explode if one isn't paying attention. While for very popular applications minor decreases in size can compound into large real-world effects.

bundlephobia.com/package/react will show you the minified and zipped size as 2.8 kB when you add it as a dependency. This doesn't include the react-dom package required for the browser which weighs in at a whopping 39.4 kB.

The tool also shows the composition with it's dependencies as shared dependencies might reduce the size further. It also indicates whether the package is marked as side-effect free and therefore predispositioned to further reductions in size once bundled for production when one only requires a subset of functionalities.

Size comparisons are especially useful when evaluating libraries for a functionality used only once but with big differences in size between packages and sometimes even implementing exactly what you need yourself.

bundle.js.org takes analyzing the detailed size after tree-shaking into focus. This will give you a more realisic size when analyzing a specific use case for packages with the possibility of tree-shaking. To do this simply export the dependencies you would otherwise import and get the size of the resulting bundle.

The size of the UI library naven will decrease by five kilobites when only the basic components are used. This can be seen after pressing run and comparing the result to using all components with export * from 'naven'.