4 ms·

How to write a silly post about JavaScript dependencies: - Don't mention other languages, lest you reveal that most of them have similar dependency bloat probl

by tmcw 6y ago

How to write a silly post about JavaScript dependencies: - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. - Talk about devDependencies and dependencies without considering how they might be entirely different, say… one kind gets bundled, the other doesn't. - Always use npm, so you can highlight duplicates. Don't use yarn. - Adopt a narrow definition of 'dependency hell' so you can focus on the thing that JavaScript does imperfectly (minimizing number of dependencies) and avoid talking about the things that it does well (handling conflicting deps, solving diamond deps, resolving dependency chains) - Don't worry about explaining how any of the issues you're discussing have real-world implications. Have companies been failing because they run out of disk space because of node_modules? - Take automated security audits extremely seriously. A backtracking bug in the argument parser for the web framework's local CLI tool? Of course it's not exploitable, when… it's a web app, and the CLI tool is something you run locally. But add it to the count as if it is!

seemslegit 6y ago
How to downplay the severity of the problem: Ignore the ridiculously small functionality scope that acceptably qualifies for a js package in a way that does not exist in any other ecosystem and ads a big multiplier in front of all the other risks involved.
- jessaustin 6y ago
  If these claims were true, we would have seen some examples by now. Instead, we get some tired invocations of "leftpad!" along with some more tired FUD. Who has been hacked because they used javascript instead of some other "more mature" language?
  - seemslegit 6y ago
    There is more to dependency risk than 'getting hacked' - correctness, maintainability, IP due diligence all play a role.
    - coffeefirst 6y ago
      Yes. I've had several apps that can basically never be upgraded due to complete insanity deep in their dependency trees. I'm pretty cautious about third party dependancies, but some of those libraries' libraries are not, and it's really hard to see that coming. If you expect to live with code for 5+ years (and I understand that's not everyone, but it's almost always me), this is a big problem.
      - jessaustin 6y ago
        We've all lived with code that was 5+ years old, even if not all those years were ours. b^) Often that meant wrangling envars to point to the right ancient binaries, assuming we could somehow get those binaries installed. None of that is required with javascript. If a dependency is causing problems, just replace it with a different one. (npmjs.com has lots of packages!) Or, write something yourself. In five years you'll find enough spare time.
rootlocus 6y ago
> - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. The post contains a graph with the package counts for other languages [1] 1 https://d33wubrfki0l68.cloudfront.net/7481900a584f733e7e9db76c4d52e06013c4e2b2/97966/images/blog/2020-04/module-counts.png https://d33wubrfki0l68.cloudfront.net/7481900a584f733e7e9db7...
- ng12 6y ago
  Is node's biggest crime is that it's easy to publish packages? Is this an argument for intentionally complicating package systems?
  - lmkg 6y ago
    The issue with NPM is that packages tend to be more granular than other languages. For example: The npm package "is-even" depends on the "is-odd" package. (In case it's not clear, this is a real package, not a made-up example.) In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. In NPM, they are separate packages. I believe there is, or was, a technical reason for NPM to have very fine-grained imports. Perhaps something about not supporting partial imports? I can't exactly find it. But the point is: NPM having more packages does not translate to a larger and more vibrant ecosystem. In some cases it simply means accomplishing the same thing requires a larger dependency graph. That's not to say it's inherently a bad thing. But that's at least why it's not inherently a good thing either. [1] https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even
    - jdminhbg 6y ago
      > In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. This is the root of all the many issues. There is no standard library. So things that are trivial to write but also dumb to rewrite every time you need them (left-pad a great example) turn into tiny dependencies.
    - 6y ago
ng12 6y ago
They also strategically avoid mentioning the payoff which is that your project is entirely self-contained. `node_modules` is at once your complete development kit, build tool, compiler, and collection of runtime dependencies. Once you check out a node project with a package.json you can reasonably assume you can install it and run it anywhere. A docker image for a node project should just be "install node && npm build". You're side-stepping the entire dev ops nightmare. Find me another language with JavaScript's popularity and that level of simplicity. I'd go as far to argue that this is what happens to any massively popular language that has a functional package manager from day one.
- stickfigure 6y ago
  I'm totally baffled by this statement. Find me a mainstream language that's more complicated than this? "Checkout and build" works pretty much everywhere? I mean, you need the right version of mvn or pip or whatnot... just like you need the right version of npm. If anything, node/npm deserves special mention for NOT having reliable repeatable builds. Part of this is that a lot of packages rely on native code. But most of it is that the ecosystem culture defaults to "always grab the latest versions of everything". And npm only got package-lock.json a few years ago, not "from day one". Prior to package-lock.json, builds were wildly unpredictable - like, expect breaking changes week to week even if you don't change anything at all in your code. If you want an "entirely self contained" payoff, languages that produce static binaries are pretty hard to beat. Node is not that.
  - tossup8536 6y ago
    Heck, in javaland the paractice now is to put the build tool in the repo, as you will only update maven once in every decade git won't complain too much about the binary, or you can just update the version in the wrapper and put the binary on the git ignore. First time you run it, it will update the build tool. Nowadays on javaland you should only need to have JDK and git/svn/hg/(wtv version control you use). And with the JDK, you can always download the most recent that java is backwards compatible.
  - aaomidi 6y ago
dmitrygr 6y ago
> - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. no such problems in C, i promise you

by tmcw 6y ago

seemslegit 6y ago

How to downplay the severity of the problem: Ignore the ridiculously small functionality scope that acceptably qualifies for a js package in a way that does not exist in any other ecosystem and ads a big multiplier in front of all the other risks involved.

jessaustin 6y ago
If these claims were true, we would have seen some examples by now. Instead, we get some tired invocations of "leftpad!" along with some more tired FUD. Who has been hacked because they used javascript instead of some other "more mature" language?
- seemslegit 6y ago
  There is more to dependency risk than 'getting hacked' - correctness, maintainability, IP due diligence all play a role.
  - coffeefirst 6y ago
    Yes. I've had several apps that can basically never be upgraded due to complete insanity deep in their dependency trees. I'm pretty cautious about third party dependancies, but some of those libraries' libraries are not, and it's really hard to see that coming. If you expect to live with code for 5+ years (and I understand that's not everyone, but it's almost always me), this is a big problem.
    - jessaustin 6y ago
      We've all lived with code that was 5+ years old, even if not all those years were ours. b^) Often that meant wrangling envars to point to the right ancient binaries, assuming we could somehow get those binaries installed. None of that is required with javascript. If a dependency is causing problems, just replace it with a different one. (npmjs.com has lots of packages!) Or, write something yourself. In five years you'll find enough spare time.

rootlocus 6y ago

> - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. The post contains a graph with the package counts for other languages [1] 1 https://d33wubrfki0l68.cloudfront.net/7481900a584f733e7e9db76c4d52e06013c4e2b2/97966/images/blog/2020-04/module-counts.png https://d33wubrfki0l68.cloudfront.net/7481900a584f733e7e9db7...

ng12 6y ago
Is node's biggest crime is that it's easy to publish packages? Is this an argument for intentionally complicating package systems?
- lmkg 6y ago
  The issue with NPM is that packages tend to be more granular than other languages. For example: The npm package "is-even" depends on the "is-odd" package. (In case it's not clear, this is a real package, not a made-up example.) In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. In NPM, they are separate packages. I believe there is, or was, a technical reason for NPM to have very fine-grained imports. Perhaps something about not supporting partial imports? I can't exactly find it. But the point is: NPM having more packages does not translate to a larger and more vibrant ecosystem. In some cases it simply means accomplishing the same thing requires a larger dependency graph. That's not to say it's inherently a bad thing. But that's at least why it's not inherently a good thing either. [1] https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even
  - jdminhbg 6y ago
    > In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. This is the root of all the many issues. There is no standard library. So things that are trivial to write but also dumb to rewrite every time you need them (left-pad a great example) turn into tiny dependencies.
  - 6y ago

ng12 6y ago

They also strategically avoid mentioning the payoff which is that your project is entirely self-contained. `node_modules` is at once your complete development kit, build tool, compiler, and collection of runtime dependencies. Once you check out a node project with a package.json you can reasonably assume you can install it and run it anywhere. A docker image for a node project should just be "install node && npm build". You're side-stepping the entire dev ops nightmare. Find me another language with JavaScript's popularity and that level of simplicity. I'd go as far to argue that this is what happens to any massively popular language that has a functional package manager from day one.

stickfigure 6y ago
I'm totally baffled by this statement. Find me a mainstream language that's more complicated than this? "Checkout and build" works pretty much everywhere? I mean, you need the right version of mvn or pip or whatnot... just like you need the right version of npm. If anything, node/npm deserves special mention for NOT having reliable repeatable builds. Part of this is that a lot of packages rely on native code. But most of it is that the ecosystem culture defaults to "always grab the latest versions of everything". And npm only got package-lock.json a few years ago, not "from day one". Prior to package-lock.json, builds were wildly unpredictable - like, expect breaking changes week to week even if you don't change anything at all in your code. If you want an "entirely self contained" payoff, languages that produce static binaries are pretty hard to beat. Node is not that.
- tossup8536 6y ago
  Heck, in javaland the paractice now is to put the build tool in the repo, as you will only update maven once in every decade git won't complain too much about the binary, or you can just update the version in the wrapper and put the binary on the git ignore. First time you run it, it will update the build tool. Nowadays on javaland you should only need to have JDK and git/svn/hg/(wtv version control you use). And with the JDK, you can always download the most recent that java is backwards compatible.
- aaomidi 6y ago

dmitrygr 6y ago

> - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. no such problems in C, i promise you