Hacker News Reader

Comment by rectang | Hacker News Reader

Even if you don't do that yourself, the culture is such that lots of NPM authors would rather add a dependency — thinking nothing of the additional security risk due to package takeover, nor the cost to downstream users who might actually want to audit their dependencies.

The result is that instead of a dependency tree of consisting of a few packages or a few dozen, you end up with an unmanageable number like 1700 coming from who knows how many authors.

View on HN

I would not completely blame it on culture. There are practical upsides to having a large number of packages - using a dependency instead of duplicating code means the resulting code is smaller, and splitting large packages up allows you to only include specific functions you need. This is important for the web, which is a lot more size sensitive.

Nowadays tree shaking means that having a large package with lots of smaller function should work better, especially since adding an import incurs its own overhead, but a lot of older packages are stuck on the small packages model.

I see "tree shaking" as a common defense (too often IMO) from people arguing over bloated code and dependencies.

But in this case, tree shaking simply doesn't occur at all in this scenario since npm modules are installed on the backend, and tree shaking simply doesn't occur on the backend.

This is what I've always thought the reason was as well. The JS ecosystem (at least since NPM has been around) has been about giving you the ability to not have to pull in a bloated, unfocused library. The complaints people have of libraries like that aren't even exclusive to the web. People working with C++ have long taken issue with massive dependencies. If the library is shipped as a DLL, then you end up bringing along all the code inside whether you use it or not.

But methods of removing unused code do a lot to take care of the problems that people have with larger libraries. In C++, header-only libraries help with the deployment size since it will only compile in what you're using. In Javascript, tree shaking will have the same effect.

It seems that if the Javascript ecosystem isn't moving towards larger libraries, it probably should. It would be much nicer to have one large library from a trusted source instead of a thousand small ones from who knows who.

> If the library is shipped as a DLL, then you end up bringing along all the code inside whether you use it or not.

Chances are, only parts of it would actually be loaded into memory due to how operating systems work.

Even if that's the case, you're still shipping the whole library. It's not an uncommon complaint that the file size of applications is massive (here on HN anyway, outside of tech I don't know if people really take notice).

I work in an org with a few tens of "microservices". Some are written in python, some in go, and some in js or typescript. The each yarn.lock file, individually, is bigger than the whole JS application it serves, and bigger than most of our microservices written in python or golang in their entirety (including their lock files which are like 40 to 100 lines). These js dependency trees are completely un-reviewable and absolutely absurd.

The theory about tiny libraries enabling tiny programs might work if developers were targeting microcontrollers, but developers have comparatively infinite cpu, memory, and disk, they've lost perspective, and the result is truly ABSURD. 10 big fat libraries are smaller than 2000 micro-libraries.

Ignoring tree shaking for a second.

If I have a library that needs to handle a bunch of general cases, but I only need 1 or 2 of them - it's probably less code to just write out those cases myself.

As a trite example, look at the source code for `is-even`. It imports the is-odd package, and the is-odd package has a bunch of error checking (and imports a library "is-number" to check errors too!) before it returns `n % 2 === 1` to is-even just to be negated.

Now blow this insanity up to all your packages of various sizes and you have a tonne of useless code that nobody needs.

Reply on news.ycombinator.com