While exploring GitHub or NPM you can see that many packages use badges - small rectangles that show package metrics and characteristics. I noticed that these badges are often perceived as indicators of the package quality. This is especially true for the bundle size badges, which use beautiful numbers and a green background to manipulate our choice. I suppose these badges are not what they seem at first glance and in practice mean nothing.

To make the article more visual, let's look at such popular CSS-in-JS libraries as Emotion CSS and Styled Components as an example.

Reason #1: bundle size !== package install size

There are two excellent services for estimating package size - Bundlephobia and Package Phobia. While the first calculates "bundle size", the second calculates "publish size" and "install size".

The "install size" is the result of recursively summing up all the package dependencies. The result of such an evaluation may surprise.

Firstly, let's take a look at the libraries badges. We are interested in gzip size and minzipped size:

Then let's look at the Package Phobia reports:

It's a pretty strong difference. The most surprising thing for me is that the install size of the framework-agnostic @emotion/css library exceeds its highly specialized competitor. This brings us to the second point.

Reason #2: bundle size !== feature-richness

Typically, the core library provides only basic functionality. This is a perfectly reasonable approach — you only load what's really needed. But on the other hand, the library author can move almost everything out of the core to achieve a minimal bundle size — and voila, beautiful bundle badges are ready.

This also relates to framework integrations. You can create framework agnostic core and lots of integrations. So actually, let's replace @emotion/css with @emotion/react. Now these libraries should be at least comparable across the framework. By the way, this version contains more different features, for example, it supports server rendering (via @emotion/server).

So, the Package Phobia report is already done.

Well, it was expected. The publish size has increased several times compared to the original, which is the price for new features. Thus, we see two approaches to feature packaging: distributed and monolithic. This division is somewhat arbitrary, because we cannot define a clear boundary between extreme cases, but simply indicate which side is closer. And this fuzziness brings us to the third point.

Reason #3: bundle size !== code performance

In Web Development high performance is often associated with a small bundle size, as pages with large resources can delay the first rendering. But if you open the Performance DevTools Panel, you will see that it is more complex. And the bottom line is that your page metrics reflect the state of the entire page, not the performance of a single library. Of course, you can compare tools in test examples. By the way, such a comparison of Emotion CSS and Styled Components has already been described in another article. But how significant is this?

The result of the work is determined not only by the tools, but also by your skills. You can have the most effective tool, but not be able to handle it, and vice versa. With experience, your skills determine the quality of the product to a greater extent.

If we go back to our examples, we need to evaluate which features of these tools are really needed. And it's always useful to evaluate native capabilities. Modern CSS allows you to flexibly customize theme via @property, isolate selectors via @scope, and write queries via @container. Also you can add or change styles dynamically via constructed stylesheets. Using native Browser APIs you can achieve success with less effort and less dependencies. Therefore, sometimes it is most effective not to use additional packages at all.

Final thoughts

So what can we say about bundle size badges?

1. They don't show how lightweight a package is.




2. They don't show how feature-rich a package is.




3. They don't show how effective a package is.

They are just numbers. I think these numbers only show the package author's approach to coding and bundling. It's probably weird to evaluate this on the positive or negative side.

And I hope that you will not judge the packages only by their bundle size badges.

Enjoy your Frontend Development!