4 ms·

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 me

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.

cj 5y ago
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.
ziml77 5y ago
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.
- deleted 5y ago
  [deleted]
- soraminazuki 5y ago
  > 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.
  - ziml77 5y ago
    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).
ploxiln 5y ago
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.
rubyist5eva 5y ago
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.

cj 5y ago

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.

ziml77 5y ago

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.

deleted 5y ago
[deleted]
soraminazuki 5y ago
> 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.
- ziml77 5y ago
  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).

ploxiln 5y ago

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.

rubyist5eva 5y ago

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.