4 ms·

Even the guys on our Node team joke that the node modules folder is abhorrently large. More massive than a black hole is the most common meme. I think there's

Even the guys on our Node team joke that the node modules folder is abhorrently large. More massive than a black hole is the most common meme. I think there's two things going on here. One, Javascript has taken Don't Repeat Yourself to an absolutely insane extreme. Python claims "batteries included" and Java boasts "there's a library for that", but it's at a higher level than stuff like is-windows. Most libraries are large and include a lot of functionality, and something like is-windows would be found inside a larger dependency like system-utils. Similarly, a Java dev would import Guava, not immutable-list and and multiset and multilist. Second, I think many Javascript devs see themselves more as plumbers than developers. The goal seems to be to stitch a bunch of dependencies together to achieve the desired outcome, rather than developing the desired outcome. I've seen plenty of people rip FileUtils.writeStringToFile out into a standalone utility class, because they didn't need all of commons-io as a dependency. In order to do that, you need to know how writeStringToFile works, and be able to fix whatever breaks when you separate it from its ecosystem. Devs that pull in is-windows don't have that kind of ... curiosity, I guess is the right word. There's no desire to see how is-windows works, or to see if they can improve it. It does what they need, so they include it as a dependency and move on, end of story. The overhead, and more importantly the security issues, involved just aren't a factor. I do wonder if the short lifespan of many UI projects is a factor, too. If you're just going to rewrite the UI in six months, there's no reason to make it efficient or maintainable.

duxup 7y ago
I asked this in another comment and maybe there is an obvious answer but: Are devs really pulling in is-windows, or are they importing some other thing (that might be more legitimate... that actually uses is-windows)? If it is the former, man I'm at a loss for words there. If it is the latter... that would seem to put the onus on the folks writing those other packages.
- mcny 7y ago
  I hate NPM with a passion but even I concede you could argue that this kind of extreme "plumbing" work is an experiment in world-wide collaboration. I mean technically you probably could make a fix in one package and everyone who uses the package benefits from it even without knowing they use the package. While I want to know how stuff works for my personal satisfaction, that's not what business cares about.
  - duxup 7y ago
    It's the best of times and the worst of times, all in one.
  - komali2 7y ago
    This also leads to shit breaking all the time. One time webpack did a breaking change (version 4) right as my team was switching from make + grunt to webpack. It was a total shitshow. Some packages were upgrading, some weren't, some did it wrong and didn't actually work on webpack4. We could have stayed on 3 but then we'd have to figure out which version wasn't broken...
qudat 7y ago
> Even the guys on our Node team joke that the node modules folder is abhorrently large. More massive than a black hole is the most common meme. This "argument" gets brought up every time there's an article about NPM. The STD library for node is relatively small so a lot of that work is outsourced to third-party libraries. The node binary is 17mb for mac os x, the node modules for a project end up 100-800mb maybe? So let's say binary + library size reaches 1GB. Now go and download visual studio to work on a C# project and wait for 15GB to be downloaded. I'm not arguing that relying on a third-party ecosystem is great as it does have legitimate security issues, but filesystem size is not the problem here.
- tntn 7y ago
  Why are you comparing the size of application dependencies to the size of an IDE that includes several compiler toolchains and tons of other build-only stuff?
  - slooonz 7y ago
    Because node_modules generally includes a "compiler toolchain" (webpack) too ?
- Sahhaese 7y ago
  Visual Studio is an IDE. A better example would be the .net SDK which is a few hundred MB, but is far more featured. The npm ecosystem is more comparable to nuget packages, but they are generally at a far more sane scope.
- fuzzy2 7y ago
  > Now go and download visual studio to work on a C# project and wait for 15GB to be downloaded. How is that even remotely comparable. Perhaps compare .NET Core SDK vs NodeJS next time.
- chrisfinazzo 7y ago
  As a bit of an accidental programmer (HTML, CSS, TeX, along with enough Node and PHP to dislike them both) can someone provide a concise distinction on the difference between the idea that something is "in the standard library" vs "part of the language?" For example, in CSS, I don't need to import a module with the syntax for Grid, it's just...there, no extra typing required.

duxup 7y ago

I asked this in another comment and maybe there is an obvious answer but: Are devs really pulling in is-windows, or are they importing some other thing (that might be more legitimate... that actually uses is-windows)? If it is the former, man I'm at a loss for words there. If it is the latter... that would seem to put the onus on the folks writing those other packages.

mcny 7y ago
I hate NPM with a passion but even I concede you could argue that this kind of extreme "plumbing" work is an experiment in world-wide collaboration. I mean technically you probably could make a fix in one package and everyone who uses the package benefits from it even without knowing they use the package. While I want to know how stuff works for my personal satisfaction, that's not what business cares about.
- duxup 7y ago
  It's the best of times and the worst of times, all in one.
- komali2 7y ago
  This also leads to shit breaking all the time. One time webpack did a breaking change (version 4) right as my team was switching from make + grunt to webpack. It was a total shitshow. Some packages were upgrading, some weren't, some did it wrong and didn't actually work on webpack4. We could have stayed on 3 but then we'd have to figure out which version wasn't broken...

qudat 7y ago

> Even the guys on our Node team joke that the node modules folder is abhorrently large. More massive than a black hole is the most common meme. This "argument" gets brought up every time there's an article about NPM. The STD library for node is relatively small so a lot of that work is outsourced to third-party libraries. The node binary is 17mb for mac os x, the node modules for a project end up 100-800mb maybe? So let's say binary + library size reaches 1GB. Now go and download visual studio to work on a C# project and wait for 15GB to be downloaded. I'm not arguing that relying on a third-party ecosystem is great as it does have legitimate security issues, but filesystem size is not the problem here.

tntn 7y ago
Why are you comparing the size of application dependencies to the size of an IDE that includes several compiler toolchains and tons of other build-only stuff?
- slooonz 7y ago
  Because node_modules generally includes a "compiler toolchain" (webpack) too ?
Sahhaese 7y ago
Visual Studio is an IDE. A better example would be the .net SDK which is a few hundred MB, but is far more featured. The npm ecosystem is more comparable to nuget packages, but they are generally at a far more sane scope.
fuzzy2 7y ago
> Now go and download visual studio to work on a C# project and wait for 15GB to be downloaded. How is that even remotely comparable. Perhaps compare .NET Core SDK vs NodeJS next time.
chrisfinazzo 7y ago
As a bit of an accidental programmer (HTML, CSS, TeX, along with enough Node and PHP to dislike them both) can someone provide a concise distinction on the difference between the idea that something is "in the standard library" vs "part of the language?" For example, in CSS, I don't need to import a module with the syntax for Grid, it's just...there, no extra typing required.