5 ms·

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, with maybe some interface info. So why do people not throw the same kind of fit about nearly every other programming environment as they do for Node/NPM? And frankly why do those other environemnts not have the ridiculous security breaches we have seen in Node/NPM land? The real problem with Node/NPM i suspect is a lack of a standard library. Simply having a standard library would have greatly reduced dependency and package hell. Further, a standard library would mean people would be more willing to write a little more code rather than include a new dependency.

fastball 6y ago
Yeah, I feel like Deno will reduce dependency usage, and people will hurrah and say "look, using URIs as deps actually worked to make things easier!", when in reality the reason dependency hell freezes over is because Deno actually has an STL.
- galaxyLogic 6y ago
  I agree. lack of standard library in Node.js means everybody has to re-invent the wheel, or find on on npm. I believe there was a time when C++ did not yet have a standard library. But now it does. JavaScript should have a standard library, not "Deno".
  - colejohnson66 6y ago
    The problem with adding to JS’s stdlib is that it’s interpreted. If the next ECMAScript version provides new features in the stdlib, it’ll take a while for browsers to adopt it, and during that time, you’ll need polyfills. Compare that to a new version of C++ where you just update your compiler, and the executable runs (almost) anywhere. No polyfills to run it.
    - fastball 6y ago
      I think the problem is less that it is interpreted and more that there are many different interpreters for different platforms, all of which are competing. Python is also interpreted, but there isn't much problem changing the stdlib because CPython runs pretty much everywhere you need it to. Sure, there are other interpreters like PyPy that also need to implement changes to the lang, but it's not a show-stopper like it is with browsers.
jfkebwjsbx 6y ago
Because in those languages: . dependencies are carefully considered by users . dependencies are not added recursively . dependencies try to be dependency-free themselves to assist with the previous point . dependencies are not blindly nor automatically updated . dependencies solve important domain problems, they are not trivial one-line-functions . dependencies are typically developed and tested by a known team or company, which you trust, not just someone random . binaries can be signed . support contracts are a thing . etc etc etc...
- muratsu 6y ago
  What you’ve said has nothing to do with languages. Claiming X devs are better than Y devs is just your bias. Other languages can be more domain specific, have more frictions around using package management, and have less nr of developers.
  - jfkebwjsbx 6y ago
    I have nowhere claimed anything about devs being better/worse.
- deleted 6y ago
  [deleted]
- lol636363 6y ago
  This is 100% true especially stupid libraries that are someone's class project. And JavaScript developers are so used to dependency hell that one of my developer imported 3rd party package for date formatting.
  - com2kid 6y ago
    JS's built in date formatting/handling is terrible and often do what needs to be one. MomentJS may be a giant import, but it works an it works really well.
    - jakobloekke 6y ago
toohotatopic 6y ago
> If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In the JVM you can use the security Manager [1] and limit file access and access to similarly sensitive areas. If you want you can fully guarantee that nothing is accessed randomly. Of course that builds on the JVM not having a zero-day bug. [1] https://en.wikipedia.org/wiki/Java_security https://en.wikipedia.org/wiki/Java_security
- poink 6y ago
  There are all kinds of things NPM users can do to mitigate security problems. The only interesting question is what the default is.
didibus 6y ago
I'm not too sure, but in Java, you depend on specific versions and the packages are signed. And most company have an internal repo they work off on, in case the public repo is having downtime or the package gets removed from it. Also deployments don't make use of dependencies, a single uberjar bundles it all up. Was this all true of NPM as well?
- brabel 6y ago
  > Also deployments don't make use of dependencies, a single uberjar bundles it all up. That's not actually completely right... there are problems with deploying a single jar. With Java 9 modules, you're actually throwing away module encapsulation if you deploy a uberjar. The current state-of-the-art is to deploy the whole app + the JVM in a jlink image, which requires no uber jar.
neurostimulant 6y ago
I remember 10 years ago (?) people were already complaining about how crazy installing some random packages via pip is instead of installing them via distro's package manager repo. The packages from distro's repo might be out of date but at least someone already vetted them they said. If someone with a time machine go back and tell them what we'll do with npm and docker today they'll probably quit programming on the spot.

fastball 6y ago

Yeah, I feel like Deno will reduce dependency usage, and people will hurrah and say "look, using URIs as deps actually worked to make things easier!", when in reality the reason dependency hell freezes over is because Deno actually has an STL.

galaxyLogic 6y ago
I agree. lack of standard library in Node.js means everybody has to re-invent the wheel, or find on on npm. I believe there was a time when C++ did not yet have a standard library. But now it does. JavaScript should have a standard library, not "Deno".
- colejohnson66 6y ago
  The problem with adding to JS’s stdlib is that it’s interpreted. If the next ECMAScript version provides new features in the stdlib, it’ll take a while for browsers to adopt it, and during that time, you’ll need polyfills. Compare that to a new version of C++ where you just update your compiler, and the executable runs (almost) anywhere. No polyfills to run it.
  - fastball 6y ago
    I think the problem is less that it is interpreted and more that there are many different interpreters for different platforms, all of which are competing. Python is also interpreted, but there isn't much problem changing the stdlib because CPython runs pretty much everywhere you need it to. Sure, there are other interpreters like PyPy that also need to implement changes to the lang, but it's not a show-stopper like it is with browsers.

jfkebwjsbx 6y ago

Because in those languages: . dependencies are carefully considered by users . dependencies are not added recursively . dependencies try to be dependency-free themselves to assist with the previous point . dependencies are not blindly nor automatically updated . dependencies solve important domain problems, they are not trivial one-line-functions . dependencies are typically developed and tested by a known team or company, which you trust, not just someone random . binaries can be signed . support contracts are a thing . etc etc etc...

muratsu 6y ago
What you’ve said has nothing to do with languages. Claiming X devs are better than Y devs is just your bias. Other languages can be more domain specific, have more frictions around using package management, and have less nr of developers.
- jfkebwjsbx 6y ago
  I have nowhere claimed anything about devs being better/worse.
deleted 6y ago
[deleted]
lol636363 6y ago
This is 100% true especially stupid libraries that are someone's class project. And JavaScript developers are so used to dependency hell that one of my developer imported 3rd party package for date formatting.
- com2kid 6y ago
  JS's built in date formatting/handling is terrible and often do what needs to be one. MomentJS may be a giant import, but it works an it works really well.
  - jakobloekke 6y ago

toohotatopic 6y ago

> If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In the JVM you can use the security Manager [1] and limit file access and access to similarly sensitive areas. If you want you can fully guarantee that nothing is accessed randomly. Of course that builds on the JVM not having a zero-day bug. [1] https://en.wikipedia.org/wiki/Java_security https://en.wikipedia.org/wiki/Java_security

poink 6y ago
There are all kinds of things NPM users can do to mitigate security problems. The only interesting question is what the default is.

didibus 6y ago

I'm not too sure, but in Java, you depend on specific versions and the packages are signed. And most company have an internal repo they work off on, in case the public repo is having downtime or the package gets removed from it. Also deployments don't make use of dependencies, a single uberjar bundles it all up. Was this all true of NPM as well?

brabel 6y ago
> Also deployments don't make use of dependencies, a single uberjar bundles it all up. That's not actually completely right... there are problems with deploying a single jar. With Java 9 modules, you're actually throwing away module encapsulation if you deploy a uberjar. The current state-of-the-art is to deploy the whole app + the JVM in a jlink image, which requires no uber jar.

neurostimulant 6y ago

I remember 10 years ago (?) people were already complaining about how crazy installing some random packages via pip is instead of installing them via distro's package manager repo. The packages from distro's repo might be out of date but at least someone already vetted them they said. If someone with a time machine go back and tell them what we'll do with npm and docker today they'll probably quit programming on the spot.