The Three Pillars of JavaScript Bloat
46 points by runxiyu
46 points by runxiyu
The “protection against global namespace mutation” argument is a crock. All it’s doing is getting you a copy of the function at time of import. If you’re worried about Math ever being compromised, you should worry about it being compromised before you import math-intrinsics.
100% agree. For example, here is the verbatim source code of the abs export:
'use strict';
/** @type {import('./abs')} */
module.exports = Math.abs;
I don't really see the point in that.
I think if you examine the actual dependency tree of a nontrivial app (e.g.), none of these will really stand out - especially if you weight by the amount they contribute to the built size, rather than simply count of packages. There is not much reason to care purely about the count of packages as opposed to their size and the total number of maintainers across all your transitive dependencies.
ljharb's packages (the first pillar) are more common in backend trees than frontend, and it's true that there is a large number of them, but they're mostly quite tiny and maintained only by him.
Having a large number of small packages instead of a smaller number of large packages (the second pillar) actually generally saves bytes in the final build: importing individual packages allows better dead code elimination (with today's tools) than importing whole namespaces like Lodash. It's only a problem if you end up with duplicate versions of packages, which is unusual and in any case duplicating a couple small packages is only going to add a small amount to your overall size.
Ponyfills for widely-supported features (the third pillar) are indeed simply bloat, but again only a very small fraction of most actual applications. It is rare to find them in popular libraries and most developers don't think to add them.
I tend to agree. I hope we can move towards an ecosystem where public packages having a large number of dependencies is frowned upon.