
Bundle Phobia: find the cost of adding an npm package to your bundle - orf
https://bundlephobia.com/?source=hnews
======
quantummkv
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.

~~~
TAForObvReasons
The flipside is that the standard library from Java / C# are huge, large
enough that there's basically one complete and proper implementation.

In JS land, you have multiple different implementations with different feature
sets and behaviors. Code written for V8/chrome/node may behave differently in
safari/jscore or IE/edge/chakra or firefox/spidermonkey.

~~~
quantummkv
This can be the case for big or difficult to implement functionality like
async/await. But for smaller functions like isArray, isObject and leftpad this
should not be the case.

C++ has a lot of different standards, compilers and implementations. There are
differences in vc++ and gcc that can prevent compilation without flags or
custom implementations. But I am sure that simple functions like printf or
strcpy behave same across implementations.

Even in Java you have Oracle JVM and android's custom dalvik/ART. But the
standard Java functions still work the same. Same with .net/mono.

------
TAForObvReasons
> 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
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.

------
pastelsky
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.

~~~
fleetfox
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.

~~~
mhaehnel
It's about emerging markets.

~~~
fleetfox
What are those? According to Wikipedia most countries have 60% 4G penetration.
Not sure what it means and how accurate it is though.

~~~
kchoudhu
Turns out 40% of several billion is a pretty large number.

------
nulagrithom
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
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

~~~
dentemple
Wouldn't using something like Yarn resolve this issue?

~~~
true_religion
No, because Yarn doesn't flatten dependencies that aren't in the same semantic
version range.

------
mStreamTeam
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
Love this tool. BundlePhobia should just merge its abilities into this thing
(or vice-versa) they'd be way powerful together

------
ianjsikes
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.vsco...](https://marketplace.visualstudio.com/items?itemName=wix.vscode-
import-cost)

------
Shoothe
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.

------
mnx
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
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-
graphic...](http://www.adriancourreges.com/blog/2017/12/15/mgs-v-graphics-
study/)

~~~
ssalazar
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
"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).

------
firloop
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.

------
sleavey
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.

~~~
busterarm
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
tried yarn?

~~~
busterarm
Yup! It has been good, we're just not using it in production yet.

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

~~~
krzkaczor
There is no overhead for typings. Type information in TS is (mostly) gone in
runtime.

~~~
evmar
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....](http://neugierig.org/software/blog/2016/04/typescript-types.html)

------
antonpug
Seems to be broken. Keeps spinning.

------
flavio81
>*"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.

~~~
abritinthebay
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
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
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.

~~~
busterarm
If eyeballs is what your metric is, that might be fine, but our traffic needs
to convert into something (in our case a form fill, in others a sale). AMP
dropped our conversion rate through the floor. And if you want analytics &
tracking, you're very limited or you have to use all/only google services.

It's a great way for google to build a captive market of content providers,
but once everyone is serving AMP pages, the benefit to brands (SERP) is gone.

~~~
abritinthebay
Conversely - we see decent conversion rates (at worst no difference to
regular) so... maybe it’s your approach?

I hate AMP with a passion but your specific objection hasn’t been true for us.

