
Size of node_modules folder when installing the top 100 packages - vnglst
https://size-of-npm.netlify.com/
======
pier25
I'm using Mithril on my current project and it includes everything you need in
less than 10kB gzipped (vdom, components, router, http client).

Another huge benefit is that it simplifies you application code immensely.
Your store and models are simply vanilla JS since Mithril doesn't have
reactivity, observables, etc. Mithril will simply redraw all the vdom whenever
a user event happens or when its router/http client do something. You can also
call m.redraw() if you need the UI to update if you for example receive
something from a web socket.

Obviously with this approach the performance cannot be as good as something
like Svelte or Inferno, but it's significantly faster than React.

[https://krausest.github.io/js-framework-
benchmark/current.ht...](https://krausest.github.io/js-framework-
benchmark/current.html)

Personally I use it with JSX since I can't stand the hyperscript notation.

It's certainly not for everyone and all use cases but I think it's totally
valid for a good portion of front end work if you can handle a double edged
knife.

~~~
ezramorse
Awesome until you look around and notice you’ve fallen into a pit of despair
(tech debt) and have no ecosystem to leverage your way out of it or people you
can hire that want anything to do with it :)

There needs to be concerns beyond pure speed and package size to dictate
tools. Sometimes real world practical constraints must be considered

~~~
jnwatson
You’re saying people don’t want to work on vanilla JavaScript? Really?

~~~
ezramorse
I’m saying check Mithril npm packages vs react/vue packages, contributed by
the people who wanted to work with each framework. Some ecosystems have more
work to pull from, more people active and experienced, and more established
patterns & tools.

------
vnglst
I thought it might be (mildly) interesting to keep track of how the npm
node_modules folder grows over time. So I made this website. Source code:
[https://github.com/vnglst/size-of-npm/](https://github.com/vnglst/size-of-
npm/)

~~~
pixelbath
I find this post a bit ironic considering you built a 1.1 MB React app to
display an image and a bit of text (and the image itself isn't even included
in the repository).

~~~
Frost1x
I don't find it ironic anymore, I find it the state of affairs in modern
development environments. I'm always surprised how quickly people jump to
using massive scaffolding, systems, or systems of systems to accomplish things
that need about two orders of magnitude less complexity.

Then again, it seems people that develop these monstrosities are never the
ones to maintain them.

~~~
ttty
You're missing out the bug picture. All my projects started small. But day
after day, you need a be feature and a new thing. It will grow. At that point
you need to add these tools yourself, manually.

I rather have a standard baseline to be up to speed and don't get bothered
with this on each app.

~~~
mark_and_sweep
> You're missing out the bug picture.

Is this a Freudian slip? The amount of bugs in "modern web apps" seems rather
huge indeed.

> I rather have a standard baseline to be up to speed

To me, the baseline for any kind of website or web app is, you know, HTML.
When authoring static HTML or rendering it dynamically on the server, I'm up
to speed instantly.

------
wruza
Yarn folks try hard (it seems) to get rid of local node_modules and link
directly to user-wide multi-version repos, but met the resistance from tool
maintainers who just walk that dir directly. I can’t remember specific details
now, but yarn pnp didn’t work for me, because of browserify and co apparently.

As of the cache size, I simply do not care. E.g. installing gnome, kde or
openoffice requires to download hundreds of megabytes of binaries and everyone
is okay with that. If you’re not familiar with these packages, they draw large
ui controls, copy files and render bad tables. Not much different from a
regular node project.

~~~
TeMPOraL
> _E.g. installing gnome, kde or openoffice requires to download hundreds of
> megabytes of binaries and everyone is okay with that_

Come on. Gnome and KDE are not equivalent of a node project, they're an
equivalent of a _browser_ (or at least browser chrome). And OpenOffice does
quite a lot more than pretty much any Node project out there.

~~~
wruza
That depends on where you draw the line. If gnome is not gtk/glib, and if kde
is not qt, then it is apples to an orange. If they are, then your comparison
is correct.

I mean, making chrome is not a big issue if you’ve got yourself
webkit/blink/presto/etc. it is a regular program, pretty stupid one, if you
think its ui out of box.

------
nkrisc
I used create-react-app recently to get up and running with React to learn
more about it and try using it. It works as advertised. However I also noticed
that I now have ~1500 dependencies in node_modules and it weighs in at about
214MB. I thought that was mildly interesting. Magic ain't cheap.

EDIT: Silly me, I was looking at the audit number. It did seem ridiculously
big.

~~~
pier25
Personally after having been bitten by some scaffolding tool I now configure
everything from scratch. Webpack is not really as complicated as it seems and
I prefer having a tailored suit instead of some generic pret a porter
solution.

Whenever I start working with a framework I create my own starter kit which I
reuse, I don't start from scratch on every project.

~~~
arvinsim
I have used CRA for so long that I have forgotten how to manually setup
Webpack.

Will try to relearn again. Hopefully, the new versions are not that bad.

~~~
have_faith
> Hopefully, the new versions are not that bad.

They are marginally better but still the user experience is horrendous. I
think a large part of it is opting for massive nested configuration objects
instead of something more similar to Gulp. You have to keep mentally parsing
the object to figure out exactly what webpack is going to do exactly.

------
derefr
So... is all this stuff actually Javascript? Or are these, say, .po
localization files, CSS+PNG template files for client libs, etc.?

Or, even worse, are these _docs_ , _tests_ , and other stuff that have no
place in the checkout of a recursively-resolved dependency?

~~~
thrower123
> Or, even worse, are these docs, tests, and other stuff that have no place in
> the checkout of a recursively-resolved dependency?

Bingo. I've seen an embarassing number of what should be dev-dependencies
pulled in transitively for some packages, as well.

Nothing like seeing some four layer deep dependency pulling gulp-cli because
somebody didn't know what they were doing...

------
Ididntdothis
I hope (and expect) that there will be larger libraries that implement the
functionality of a lot of very small packages. JavaScript really needs a
comprehensive standard library.

~~~
dan-robertson
On the other hand it tends to be harder to change things in a standard library
(ie that is where good code goes to die) for want of not breaking
dependencies.

If all libraries are tiny then a set of “the best” libraries can evolve over
time through the preferences of individual people.

Obviously this doesn’t work so well for finding libraries or having them work
great together.

~~~
enneff
Why would you want the libraries you depend on to change??

~~~
zentiggr
They have bugs, and fixing them is good? They have better implementations,
eventually, and improving performance is good?

------
kristianp
Probably lighter than Rails, whichs feels very heavy trying it again after a
while. A fresh new rails app with devise and postgresql client nets me a
vendor/bundle folder of 183MB. Of course it needs an install of node as well.

------
z3t4
Tired of all the bloat in JS, with the distributed app weighting a whopping 2
MB, I said to myself &#@£ this, I'm going to make a native app. What I ended
up with was a 300MB statically linked binary - to show "hello world".

~~~
ivanfon
What stack did you use?

~~~
z3t4
Dlang with bindings to a C GUI lib for Linux.

------
fullstackchris
I think about this stuff from time to time... If we think out into the future
(50-100 years?)... will there eventually be such a huge footprint for
frameworks / packages that there is nobody who remembers how some of the old
dependencies were written? Interesting to think of a future bug where nobody
would know the solution because it lies so deep in a dependency somewhere :)

~~~
trufas
You might find a talk[0] from Jon Blow on this very subject from last year
interesting.

[0] [https://youtu.be/pW-SOdj4Kkk](https://youtu.be/pW-SOdj4Kkk)

~~~
zemo
Jonathan Blow publicly criticizes Twitter engineering for being unproductive
because they haven't released many user-facing features. He regularly berates
the entire web industry without knowing anything about how it works.

His knowledge is limited to an extremely tiny domain of programming, and he
regularly berates people for not following his philosophy. Meanwhile, it took
him eight years to make The Witness. What did he build with his eight years
time? A first person puzzle game with essentially no interactive physics, no
character animations, and no NPC's to interact with. (I actually enjoy The
Witness, fwiw.) The vast majority of developers do not have the budget to
spend eight years on a single title, and wouldn't want to even if they did.

The most notable thing about Jonathan Blow is how condescending he is.

~~~
mrspeaker
If that's what you take away from Jonathan Blow then you need to detach from
your emotions a bit. He annoys me with how much his condescending attitude
towards web development (because I'm a web developer) - but he justifies his
positions and is open to argument about it. His talks (like that one linked
above) are really inspirational, and he's released two highly successful
product: two more than the majority of people you'll ever meet.

He's passionate and smart and interesting - and writing him off like that, I
think, is not justified.

~~~
zemo
I thought much more highly of him when I didn't work in games and I was a web
developer. Now that I work in games I don't think very highly of him. He's an
uncompromising fundamentalist that sends would-be game developers down
impossibly unproductive paths of worrying about minutia that will never matter
to their projects before they've ever built their first game. He's famous for
being a rude guest in both academia and in conferences. He's basically the
equivalent of someone that says that you should NEVER use node because
node_modules gets big and if you're writing a server it should be in Rust and
if it isn't you're bad and you should feel bad. His worldview does not at all
take into account the differing problems faced by differing people, having
differing access to resources and differing budgets and time constraints. He
is _only_ concerned with how you should work if you have no deadlines, an
essentially unlimited runway, and your most important concern is resource
efficiency. For most games projects, the production bottleneck is not CPU or
GPU efficiency: it's the cost of art production. What he has to say is, for
the vast, vast majority of people, not applicable. He is, essentially, an apex
predator of confirmation bias.

The thing about Jonathan Blow is that for a lot of people, he's the first
graphics-focused outspoken programmer that they run into and so they think
he's some form of singular genius. He isn't.

------
norswap
It would be better if it showed how much each of the top 100 packages consumed
when installed alone (along with their dependencies), as well as how much
weight they single-handedly contribute to the 100-package-install total size
(i.e. dependencies pulled by only them and no other package in the top 100).

Is the average weight high? Or are there a couple behemoths?

------
capableweb
Cool! You could even scrape the history of this. If you take a date that you
want to scrape, then you resolve the top-level packages with their release
date that you'll find next to the version in the package.json. Use the latest
found version that is before the date you're trying to scrape for.

------
bazza451
Do hate this about javascript. one of the main reasons on the web side (apart
from js not having a good STL) however is enterprises are still locked in to
IE11 which requires all these tranpilers/bundlers to use modern syntax which
usually are the heaviest of all of these dependencies.

~~~
chispamed
Vue-cli at least has a very neat feature; if you build with the —-modern flag
it will create two versions of your scripts, one with modern syntax, smaller
and faster for modern browsers and another legacy version for older browsers
you have to support. It then uses the nomodule html attribute to automatically
load the version your browser needs. This also has the nice effect of saving
you bandwidth costs.

------
geuis
Been spending the last few days building a new site for a long running project
I own.

For the server, I’m using hapijs. It fits my style a whole lot better than
Express.

For the client side, it’s entirely just raw css and js. Absolutely no
frameworks.

Eventually I’m going to have to use a few third party tools when I get around
to adding square or braintree integration but that’s a way off.

It’s an absolute joy to just sit down and get stuff done. Today I was able to
move from getting the basic node server running in under an hour to building
out a couple pages and writing some content. Added some css styling like back
in the old days and without needing less or sass. Still only about as good as
you’d expect from one day of work but it was so easy to do.

I didn’t spend hours setting up tooling, researching which extra npm modules
were needed, etc. There’s no React garbage, no Everest of overhead just to get
to a point where I could work.

~~~
chrisweekly
Your frustration with React and the npm ecosystem is common but easily
remedied; try NextJs.

~~~
1_player
NextJS has been an absolute, undocumented nightmare at our company we've gone
back to CRA and "hand rolled" SSR to retain our sanity.

It's one of those modern magic frameworks that when you need to step outside
the simple hello world example app you spend most of your days chasing buggy
behaviours mentioned on unresolved month old github issues.

When this happens, usually your only choice and suggestion is update to the
beta version of some core library, which breaks tons of other packages that
haven't yet been updated to the new rewritten API, rinse and repeat.

Never again.

To be honest, NextJS wasn't worse than the rest of the JS ecosystem, the
problem is systemic.

~~~
chrisweekly
Yikes. Your experience in no way matches mine, nor that of many others I've
worked with over the years. Using NextJs doesn't absolve you of the
responsibility to understand the fundamentals of how your webapp works, but
IMHO / IME it strikes a great balance when it comes to DX and convenience,
with direct extensibility and support to drop a layer down to do things by
hand; IOW, yeah there's some magic but it's the good kind. I'd be very
interested to hear more about your "nightmare", and what circumstances led to
the painted-corner of depending on beta versions of core libraries. Care to
elaborate?

------
zelly
If you think this is bad, it's going to get 1000x worse with WASM. A lot more
rope there. You will see the Linux kernel being pulled in because someone used
system threads.

------
bransonf
Does anyone know what that late November spike is all about?

~~~
atomwaffel
Since this tracks the combined size of the top 100 npm packages, my guess is
that those spikes are caused by packages entering and leaving the list.

~~~
bransonf
That would make sense. Probably the number 100ish spot got replaced by a much
larger package.

My initial thought was a widespread security patch or something.

------
golergka
Quote from the bottom of the website (easy to miss):

> On my Macbook Pro the folder containing Xcode is larger than 13 GB. And to
> get the .NET application running at work I had to install over 20 GB of
> applications and dependencies. So, relativity speaking, JavaScript is still
> ok.

Personally, I completely agree with that. A single gigabyte of hard drive
space on a developer's machine or a modern server is not terribly wasteful.

~~~
nizmow
But also, the point about .NET is complete garbage. The full .NET 3.1 SDK
download for Mac OS X is around 100MB. Based on that hyperbolic statement I'd
be hesitant to trust anything else on the site.

EDIT: I know he says "the application at work" and it's just an offhand
comment, but you shouldn't read too much into it. Unless it means "I had to
install Windows 10 on a VM" because it uses classic framework libraries that
don't work with Mono or something.

------
viraptor
I can't find the code that does the actual package installation. Does it do
deduplication / linking of modules, or does it install full tree?

~~~
leipert
It runs on circle CI (look at the .circleci folder). Half the logic is in
there, the other half in ./size. I am on mobile so I cannot check the
methodology, but it seems like the CI is committing the stats back to the repo

------
gjmacd
I think yarn workspaces and lerna can help reduce a lot of teh redundancy in
your project(s).

------
wafflesraccoon
Our cooperate Cisco security filter blocks the website `size-of-
npm.netlify.com` for a "security threat".

NET::ERR_CERT_AUTHORITY_INVALID is the listed error

------
keyle
Note to the author, less memes and better information... What's the chart in?
Megabytes I presume?

~~~
samirelanduk
It says MB on the y-axis label.

------
smabie
It seems to me that this website could be a completely static site that is
automatically regenerated once a day with a new graph. Instead you seem to be
succumbing to the exact same problem you are highlighting. This a good example
of how the culture of software engineering is moving in the wrong direction.
We need to all make a stand and say no more to this culture.

Of course, that’s made difficult by the fact it’s against our own collective
interest. At this rate even the worst developers will be able to be employed
managing some gargantuan and wholly unnecessary software stock.

Not to knock on you to much, but this culture of bloat reminds about the
classic “Evolution of a Programmer” joke:

[https://www.smart-jokes.org/programmer-evolution.html](https://www.smart-
jokes.org/programmer-evolution.html)

Let’s all try and be like the Guru Hacker, not the Seasoned Professional!

~~~
lucasmullens
> We need to all make a stand and say no more to this culture.

I don't think the path forward is to bash all websites that use a common npm
library.

~~~
mstade
Unfortunately the culture I’ve experienced in the past few years has been
essentially that, but for anything that does _not_ use a common npm library.
“Why is this not done with React/Vue/Typescript/Angular/<insert favorite thing
here>?” is a question that’s posed less as a question and more as a
condescension in many cases. The rebuttal “because not using XYZ works just
fine” is not often accepted, true as it may be, followed by bashing the non
believer in question into submission.

I’m with you though, I don’t think the bashing is necessary, in either
direction. It just breeds contempt.

------
marknadal
This is why I don't.

Vanilla JS! 0 Dependencies!

Let the 1995 revolution begin!

~~~
jaywalk
Have fun building anything remotely complex.

~~~
rikroots
I've had great fun building my canvas element library entirely in Vanilla JS.
The work has helped me discover parts of the JS/DOM ecosystem that I never
realised even needed to exist.

------
sneak
Unpopular opinion: 1GB is not a lot of data for most people in the first
world.

~~~
Twirrim
Most people _aren 't_ living in the first world, and don't have high bandwidth
/ low latency connections with which to make pulling down 100s of MB of
javascript a non-event.

While, yes, they can choose to just not use such tools or libraries, it also
presents a fun barrier for learning.

It's also perfectly fine to not give a damn about either of the above.

~~~
true_religion
Um. So as someone living in not the first world, let me give some perspective.
People here do not use “first world” sites. Even without the JavaScript,
sending bits across the ocean just to see an image takes too long.

Everyone uses local nation sites, some of which even use languages spoken by
no more than 5 million people world wide.

We aren’t the target market for the “first world” website, and that’s fine as
the first world isn’t the target for any of our digital goods either.

It just feels a bit patronizing when this discussion is brought up, as no one
is dying to use a random American made website. Facebook and Google are
exceptions, not the rule.

