8 ms·

Bundle Phobia: find the cost of adding an npm package to your bundle

100 points by orf 9y ago

mnx 9y ago
left-pad only adds 7ms on edge, seems worth it. On the other hand, Jquery adds almost a second. And you hardly ever see pages that don't use it. (Unless they use some other heavy js library). But it's just soo convenient.
- maccard 9y ago
  7ms is an eternity. You can do half of this [0] in 7ms or you can download one line of code. I’d be out of a job if I introduced 1/10 of that time for text padding. [0] http://www.adriancourreges.com/blog/2017/12/15/mgs-v-graphics-study/ http://www.adriancourreges.com/blog/2017/12/15/mgs-v-graphic...
  - ssalazar 9y ago
    Its completely meaningless to compare the render time of a single frame of a AAA video game with the load time of web page over a network.
    - dingdingdang 9y ago
      "completely meaningless" may well be putting it a bit harshly: there is good lessons to be learned by drawing on lessons learned across different fields of computing. 7ms is hardly anything but apply it to a list of only a 1000 elements and you have now slowed down the user experience by 7000ms (I know, this would all be buffered and hidden, etc. but this is just one tiny component and eventually all this stuff leads to real perceptible awful jankiness that could have been avoided if people allowed themselves to think a bit about performance).
- busterarm 9y ago
  I often find that most of the people who make the Jquery argument are the same people pushing Angular or React, both of which are bigger libraries...
nulagrithom 9y ago
Suggestion: also show the number of dependencies and sub-dependencies. That's usually where I run in to bundle-phobia mentality (whether its warranted or not is another discussion).
- brootstrap 9y ago
  good call, i'm a python guy who usually does science/infrastructure stuff but occasionally look at what is goin on with our front end libaries. Whenever i read thru our dep-chain i'm like holy shit guys, isArray is in here 4 times with 4 different versions. All in all though cool project, looks great, works fast, provides good info. thanks and congrats
  - oboopfmlrmnmn 9y ago
    I don’t understand if you are the author or just use a suggestive writing style.
  - dentemple 9y ago
    Wouldn't using something like Yarn resolve this issue?
    - true_religion 9y ago
      No, because Yarn doesn't flatten dependencies that aren't in the same semantic version range.
  - cJ0th 9y ago
    > isArray is in here 4 times with 4 different versions. just ... wow :D
flavio81 9y ago
>*"JavaScript bloat is more real today than it ever was. Sites continuously get bigger as more (often redundant) libraries are thrown to solve new problems." Very true, pointed criticism, but i'm afraid part of the answer is avoiding npm altogether.
- nulagrithom 9y ago
  How does avoiding the use of a package manager fix bloat? Or do you mean to say everyone should be writing vanilla JS with zero dependencies?
- abritinthebay 9y ago
  Not true. A massive majority of that code you download is from 3rd parties. Ads, tracking, analytics, Instagram & Facebook embeds, etc... Now you can suggest that we should move to not having any of these but from a business perspective that’s... very hard. Trimming is possible, of course, but the reality is that npm is not the problem- sites were bloated with JS before it came along.
  - busterarm 9y ago
    My company's entire business revolves around embedding tracking and analytics JS on our page and serving it to people and all of those plugins combined are still dwarfed by something like React or Angular by a factor of 2x. The problem ends up being when you're embedding this stuff and the provider has their own dependencies they're loading. Hubspot's embedded web forms pulls in an entire React framework. Mess. If you're serious about doing this stuff, you include the bare minimum JS possible (GA/GTM, usually), store GUIDs in your request logs and put that into your analytics data pipeline. And keep telling the Google rep to take a hike when they put pressure on you to use AMP.
    - abritinthebay 9y ago
      Sure, I’ll believe you and not what the browser reports. AMP may be bullshit but it means a 5-10x increase in traffic so... again, missing the business case.
mStreamTeam 9y ago
I've used this NPM graph tool in the past to determine the cost of adding a dependency: http://npm.anvaka.com/#/ http://npm.anvaka.com/#/
- warent 9y ago
  Love this tool. BundlePhobia should just merge its abilities into this thing (or vice-versa) they'd be way powerful together
TAForObvReasons 9y ago
> This thing lets you understand the performance cost of npm install ing a new npm package before actually adding it to your bundle. Unless you are specifically concerned about the `npm install` performance in node, in which case the npm package size is relevant, you never include the whole NPM package in your bundle. Most universal packages include separate dist files and separate entry points for node usage, so most of the content is actually not included. If you are truly interested in bloat, let your bundler give you a summary at the end. Webpack can give you detailed information about what files were included, how much each file costs, and why the costs were incurred.
- mercer 9y ago
  Lodash is a good example of this. The whole package is pretty big, and includes a functional programming variant (which I suppose is mostly wrappers around the other stuff, but it still adds weight). So in practice you'll pretty much never be using the full package on account of 1) going for either require('lodash') or require('lodash/fp'), but not both, and 2) requiring specific functions through require('lodash/each') or whatnot. The only way to get an accurate picture is to analyse the bundled package, or I suppose as part of the pipeline of whatever packaging solution you use.
quantummkv 9y ago
The real problem with npm and JavaScript is not the package manager, it is the lack of a standard library bundled with the runtime that has such basic functions. To someone coming to JavaScript from a Java/C# world, the fact that a package like isArray actually exists, nevermind the ridiculous number of downloads it has, is mind boggling. Using a dependency like this on a Java project will get you crucified in any sane team. If you want to get out of this dependency hell, bundle these small, essential functions into the runtime.
- woogley 9y ago
  Depends on the team. I would not approve anything other than using a runtime library or importing 'core-js/fn/array/is-array' from the wonderfully modular core-js: https://github.com/zloirock/core-js https://github.com/zloirock/core-js Although for this particular strawman I think `foo.constructor === Array` is probably enough.
  - deleted 9y ago
    [deleted]
  - alaaibrahim 9y ago
    What if foo is `null` or `undefined` ?
- banjomonster 9y ago
  Array.isArray is available in the runtime, but it was a later addition so folks may be downloading it for compatibility. There is a LOT of that in the javascript ecosystem. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- styfle 9y ago
  They are bundled, it’s called ES6/ES2015. But for backwards compatibility, the userland packages are still used regularly.
  - 9y ago
antonpug 9y ago
Seems to be broken. Keeps spinning.
sleavey 9y ago
I didn't realise that others also actively avoid npm. I can't really place my finger on exactly why I do, but I guess it's somewhere between the cargo-cult mentality in Javascript (which makes me associate node packages with poor quality programming) and not seeing the point of having another package manager beyond what my distro provides.
- oboopfmlrmnmn 9y ago
  There is a big distinction between the purpose of your distro package manager and the purpose of a languange dependency manager such as npm, pip, rubygems, cargo or composer. While the first is for installing applications on your system (and also used for c libraries, because c has no official dependency manager), the second serves much more specialized purposes tailored for the language, such as - os-agnostic (imagine the work in getting all them distros update just one package) - compiles/postprocesses dependencies in deterministic ways - etc.
- busterarm 9y ago
  Any projects we do where npm packages are a dependency inevitably end up with frequent transient build failures. npm install will kick out with some warning or error that's buried well past the 4MB log limit from CircleCI. Rebuilding the project always works. I haven't been able to determine if this is an NPM issue or CircleCI issue, but short research periods seem to indicate the former, and I find the availability of packages in the manager to be 'unreliable'. That's not really something that I want to deal with in software that is managing my dependencies, but that's the state of the world. Apt repositories have a tendency to do the same thing, actually.
  - oboopfmlrmnmn 9y ago
    tried yarn?
    - busterarm 9y ago
      Yup! It has been good, we're just not using it in production yet.
pastelsky 9y ago
Author here. I made this because finding package sizes of front end libraries was a pain, especially after modular javascript caught on. You can also see size results now when browsing a package on yarnpkg.com (look for "Size in browser") or as a sheild on some repos (WIP). Suggestions welcome.
- Yokohiii 9y ago
  Wouldn't it make more sense to optinally add all dependencies?
  - pastelsky 9y ago
    If you're the author of `react-button`, it wouldn't make sense to add `react` + `react-dom` to account for it's size. In most cases, peer dependencies are already present in the user's projects.
- mintblue 9y ago
  Really cool site, material breaks it though. Can't find dependency "button" :) Thanks for building!
- tytytytytytytyt 9y ago
  Can you fix this? MissingDependencyError This package (or this version) uses `./lib-cov/http`, but does not specify them either as a dependency or a peer dependency For input chai-http
- fleetfox 9y ago
  Where are you from that 3G is "emerging"? I think we have like 90% LTE coverage for major providers, just a question of hardware supporting that.
  - nathancahill 9y ago
    Oh boy. Guys, should we tell him?
  - 9y ago
firloop 9y ago
I would love a version of this where you could paste in your package.json and it adds up all your dependencies and offers suggestions of popular dependencies that can be removed.
Shoothe 9y ago
Leftpad: https://bundlephobia.com/result?p=leftpad@0.0.1 https://bundlephobia.com/result?p=leftpad@0.0.1 looks good, let's use it! But seriously great service, I was thinking about a CLI tool like this to estimate dependency impact before using it.
WaxProlix 9y ago
It doesn't look like TypeScript bindings work on this, but it'd be nice to see the overhead of @types/ packages.
- krzkaczor 9y ago
  There is no overhead for typings. Type information in TS is (mostly) gone in runtime.
  - evmar 9y ago
    I think type info in TS is 100% gone in runtime. Here's a blog post that explores why you can be confident of this: http://neugierig.org/software/blog/2016/04/typescript-types.html http://neugierig.org/software/blog/2016/04/typescript-types....
ianjsikes 9y ago
Here's a great VS Code extension that shows package size inline next to your import/require statements: https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost https://marketplace.visualstudio.com/items?itemName=wix.vsco...

100 points by orf 9y ago

mnx 9y ago

left-pad only adds 7ms on edge, seems worth it. On the other hand, Jquery adds almost a second. And you hardly ever see pages that don't use it. (Unless they use some other heavy js library). But it's just soo convenient.

maccard 9y ago
7ms is an eternity. You can do half of this [0] in 7ms or you can download one line of code. I’d be out of a job if I introduced 1/10 of that time for text padding. [0] http://www.adriancourreges.com/blog/2017/12/15/mgs-v-graphics-study/ http://www.adriancourreges.com/blog/2017/12/15/mgs-v-graphic...
- ssalazar 9y ago
  Its completely meaningless to compare the render time of a single frame of a AAA video game with the load time of web page over a network.
  - dingdingdang 9y ago
    "completely meaningless" may well be putting it a bit harshly: there is good lessons to be learned by drawing on lessons learned across different fields of computing. 7ms is hardly anything but apply it to a list of only a 1000 elements and you have now slowed down the user experience by 7000ms (I know, this would all be buffered and hidden, etc. but this is just one tiny component and eventually all this stuff leads to real perceptible awful jankiness that could have been avoided if people allowed themselves to think a bit about performance).
busterarm 9y ago
I often find that most of the people who make the Jquery argument are the same people pushing Angular or React, both of which are bigger libraries...

nulagrithom 9y ago

Suggestion: also show the number of dependencies and sub-dependencies. That's usually where I run in to bundle-phobia mentality (whether its warranted or not is another discussion).

brootstrap 9y ago
good call, i'm a python guy who usually does science/infrastructure stuff but occasionally look at what is goin on with our front end libaries. Whenever i read thru our dep-chain i'm like holy shit guys, isArray is in here 4 times with 4 different versions. All in all though cool project, looks great, works fast, provides good info. thanks and congrats
- oboopfmlrmnmn 9y ago
  I don’t understand if you are the author or just use a suggestive writing style.
- dentemple 9y ago
  Wouldn't using something like Yarn resolve this issue?
  - true_religion 9y ago
    No, because Yarn doesn't flatten dependencies that aren't in the same semantic version range.
- cJ0th 9y ago
  > isArray is in here 4 times with 4 different versions. just ... wow :D

flavio81 9y ago

>*"JavaScript bloat is more real today than it ever was. Sites continuously get bigger as more (often redundant) libraries are thrown to solve new problems." Very true, pointed criticism, but i'm afraid part of the answer is avoiding npm altogether.

nulagrithom 9y ago
How does avoiding the use of a package manager fix bloat? Or do you mean to say everyone should be writing vanilla JS with zero dependencies?
abritinthebay 9y ago
Not true. A massive majority of that code you download is from 3rd parties. Ads, tracking, analytics, Instagram & Facebook embeds, etc... Now you can suggest that we should move to not having any of these but from a business perspective that’s... very hard. Trimming is possible, of course, but the reality is that npm is not the problem- sites were bloated with JS before it came along.
- busterarm 9y ago
  My company's entire business revolves around embedding tracking and analytics JS on our page and serving it to people and all of those plugins combined are still dwarfed by something like React or Angular by a factor of 2x. The problem ends up being when you're embedding this stuff and the provider has their own dependencies they're loading. Hubspot's embedded web forms pulls in an entire React framework. Mess. If you're serious about doing this stuff, you include the bare minimum JS possible (GA/GTM, usually), store GUIDs in your request logs and put that into your analytics data pipeline. And keep telling the Google rep to take a hike when they put pressure on you to use AMP.
  - abritinthebay 9y ago
    Sure, I’ll believe you and not what the browser reports. AMP may be bullshit but it means a 5-10x increase in traffic so... again, missing the business case.

mStreamTeam 9y ago

I've used this NPM graph tool in the past to determine the cost of adding a dependency: http://npm.anvaka.com/#/ http://npm.anvaka.com/#/

warent 9y ago
Love this tool. BundlePhobia should just merge its abilities into this thing (or vice-versa) they'd be way powerful together

TAForObvReasons 9y ago

> This thing lets you understand the performance cost of npm install ing a new npm package before actually adding it to your bundle. Unless you are specifically concerned about the `npm install` performance in node, in which case the npm package size is relevant, you never include the whole NPM package in your bundle. Most universal packages include separate dist files and separate entry points for node usage, so most of the content is actually not included. If you are truly interested in bloat, let your bundler give you a summary at the end. Webpack can give you detailed information about what files were included, how much each file costs, and why the costs were incurred.

mercer 9y ago
Lodash is a good example of this. The whole package is pretty big, and includes a functional programming variant (which I suppose is mostly wrappers around the other stuff, but it still adds weight). So in practice you'll pretty much never be using the full package on account of 1) going for either require('lodash') or require('lodash/fp'), but not both, and 2) requiring specific functions through require('lodash/each') or whatnot. The only way to get an accurate picture is to analyse the bundled package, or I suppose as part of the pipeline of whatever packaging solution you use.

quantummkv 9y ago

The real problem with npm and JavaScript is not the package manager, it is the lack of a standard library bundled with the runtime that has such basic functions. To someone coming to JavaScript from a Java/C# world, the fact that a package like isArray actually exists, nevermind the ridiculous number of downloads it has, is mind boggling. Using a dependency like this on a Java project will get you crucified in any sane team. If you want to get out of this dependency hell, bundle these small, essential functions into the runtime.

woogley 9y ago
Depends on the team. I would not approve anything other than using a runtime library or importing 'core-js/fn/array/is-array' from the wonderfully modular core-js: https://github.com/zloirock/core-js https://github.com/zloirock/core-js Although for this particular strawman I think `foo.constructor === Array` is probably enough.
- deleted 9y ago
  [deleted]
- alaaibrahim 9y ago
  What if foo is `null` or `undefined` ?
banjomonster 9y ago
Array.isArray is available in the runtime, but it was a later addition so folks may be downloading it for compatibility. There is a LOT of that in the javascript ecosystem. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
styfle 9y ago
They are bundled, it’s called ES6/ES2015. But for backwards compatibility, the userland packages are still used regularly.
- 9y ago

antonpug 9y ago

Seems to be broken. Keeps spinning.

sleavey 9y ago

I didn't realise that others also actively avoid npm. I can't really place my finger on exactly why I do, but I guess it's somewhere between the cargo-cult mentality in Javascript (which makes me associate node packages with poor quality programming) and not seeing the point of having another package manager beyond what my distro provides.

oboopfmlrmnmn 9y ago
There is a big distinction between the purpose of your distro package manager and the purpose of a languange dependency manager such as npm, pip, rubygems, cargo or composer. While the first is for installing applications on your system (and also used for c libraries, because c has no official dependency manager), the second serves much more specialized purposes tailored for the language, such as - os-agnostic (imagine the work in getting all them distros update just one package) - compiles/postprocesses dependencies in deterministic ways - etc.
busterarm 9y ago
Any projects we do where npm packages are a dependency inevitably end up with frequent transient build failures. npm install will kick out with some warning or error that's buried well past the 4MB log limit from CircleCI. Rebuilding the project always works. I haven't been able to determine if this is an NPM issue or CircleCI issue, but short research periods seem to indicate the former, and I find the availability of packages in the manager to be 'unreliable'. That's not really something that I want to deal with in software that is managing my dependencies, but that's the state of the world. Apt repositories have a tendency to do the same thing, actually.
- oboopfmlrmnmn 9y ago
  tried yarn?
  - busterarm 9y ago
    Yup! It has been good, we're just not using it in production yet.

pastelsky 9y ago

Author here. I made this because finding package sizes of front end libraries was a pain, especially after modular javascript caught on. You can also see size results now when browsing a package on yarnpkg.com (look for "Size in browser") or as a sheild on some repos (WIP). Suggestions welcome.

Yokohiii 9y ago
Wouldn't it make more sense to optinally add all dependencies?
- pastelsky 9y ago
  If you're the author of `react-button`, it wouldn't make sense to add `react` + `react-dom` to account for it's size. In most cases, peer dependencies are already present in the user's projects.
mintblue 9y ago
Really cool site, material breaks it though. Can't find dependency "button" :) Thanks for building!
tytytytytytytyt 9y ago
Can you fix this? MissingDependencyError This package (or this version) uses `./lib-cov/http`, but does not specify them either as a dependency or a peer dependency For input chai-http
fleetfox 9y ago
Where are you from that 3G is "emerging"? I think we have like 90% LTE coverage for major providers, just a question of hardware supporting that.
- nathancahill 9y ago
  Oh boy. Guys, should we tell him?
- 9y ago

firloop 9y ago

I would love a version of this where you could paste in your package.json and it adds up all your dependencies and offers suggestions of popular dependencies that can be removed.

Shoothe 9y ago

Leftpad: https://bundlephobia.com/result?p=leftpad@0.0.1 https://bundlephobia.com/result?p=leftpad@0.0.1 looks good, let's use it! But seriously great service, I was thinking about a CLI tool like this to estimate dependency impact before using it.

WaxProlix 9y ago

It doesn't look like TypeScript bindings work on this, but it'd be nice to see the overhead of @types/ packages.

krzkaczor 9y ago
There is no overhead for typings. Type information in TS is (mostly) gone in runtime.
- evmar 9y ago
  I think type info in TS is 100% gone in runtime. Here's a blog post that explores why you can be confident of this: http://neugierig.org/software/blog/2016/04/typescript-types.html http://neugierig.org/software/blog/2016/04/typescript-types....

ianjsikes 9y ago

Here's a great VS Code extension that shows package size inline next to your import/require statements: https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost https://marketplace.visualstudio.com/items?itemName=wix.vsco...