4 ms·

That is special about JS here? AFAICT the same is true for every python package, every rust crate, every linux package, every ruby gem, etc.... Maybe all of th

That is special about JS here? AFAICT the same is true for every python package, every rust crate, every linux package, every ruby gem, etc.... Maybe all of those need the same scrutiny but AFAIK they fundamentally have the same issue.

ryukafalz 5y ago
That is correct, these all fundamentally have the same issue and all need the same scrutiny.
Sohcahtoa82 5y ago
Python developers are slightly better behaved. I can't possibly come up with a reason WHY (Maybe Python's standard library is that much better than Node?), but Python dependency trees just tend to be so much simpler. If I "pip install $PACKAGE", it's usually only a couple additional dependencies that get included unless it's one of the huge ones like numpy. If I "npm install $PACKAGE", I can expect 50+ additional dependencies to get added. For some reason, Node engineers are much more likely to "npm install leftpad" than write the 2 lines of code it takes to implement string padding.
- verelo 5y ago
  The JS standard library is very slim. I think this is both its greatest strength and weakness, and to your point, makes it likely that people just install some random package v's solve the problem themselves. I'm not sure which is better philosophically, but personally having done a lot of PHP dev in the last decade I find the JS code i'm writing to be easier to read but much harder to understand and run from a package management perspective. I think the developers working on solutions in JS would probably behave very different if they were given more built in tools to work with.
  - paulmd 5y ago
    the same is true of java - less so in newer versions, but older versions the stdlib was pretty slim and low-level and there was a massive amount of library code written to wrap around it. it still doesn't devolve to the javascript phenomenon of one-file (or one-function) libraries and so on. Dozens of libraries, sure, hundreds, maybe, but nobody actually has thousands of dependencies like you do on node. Apparently "number of repos maintained" is a KPI so there's some gamesmanship there. Maybe it's also being used as a caching thing, smaller files might be more cacheable if you don't minify? More generally though this may be the result of that "enterprise culture" that is sometimes looked down on in other situations, that at least stuff is getting bundled into appropriate packages for distribution vs just chucking every single file into a node package.
- ratww 5y ago
  The problem in Javascript is localized. Lots of extremely important foundational packages like React, Vue, Typescript, and even ones like Prettier don't really have lots of dependencies. The biggest culprits of the craziness are things like Babel and Webpack, which require tens or sometimes hundreds of packages for a basic install. Some of those aren't really needed in Python, for example. But in JS there are alternatives to them. On the other hand, some foundational packages in languages like Python and Ruby have a lot of dependencies. I don't know about Python much, but Rails also has a large dependency graph, despite Ruby having a good standard library.
forty 5y ago
Exactly, I'm not sure what people are trying to fix here. They want code they import in their projects to be sandboxed so they import untrusted code. That seems a bit f*cked up to me. Running untrusted apps is already pretty hard, running apps where some code is trusted and some not, seems... a bad idea. IMO since the problem is generic to all languages we should have a generic solution, using standard sandboxing technics (containers, VMs, jail, etc)
- gwright 5y ago
  Makes me think of Plan 9 and its almost religious use of the 9P protocol to control what resources are available to a process. Or perhaps the Erlang VM with communication via messages. Composing systems in this way is very different than adding untrusted code to your application but seems like an interesting alternative approach.

ryukafalz 5y ago

That is correct, these all fundamentally have the same issue and all need the same scrutiny.

Sohcahtoa82 5y ago

Python developers are slightly better behaved. I can't possibly come up with a reason WHY (Maybe Python's standard library is that much better than Node?), but Python dependency trees just tend to be so much simpler. If I "pip install $PACKAGE", it's usually only a couple additional dependencies that get included unless it's one of the huge ones like numpy. If I "npm install $PACKAGE", I can expect 50+ additional dependencies to get added. For some reason, Node engineers are much more likely to "npm install leftpad" than write the 2 lines of code it takes to implement string padding.

verelo 5y ago
The JS standard library is very slim. I think this is both its greatest strength and weakness, and to your point, makes it likely that people just install some random package v's solve the problem themselves. I'm not sure which is better philosophically, but personally having done a lot of PHP dev in the last decade I find the JS code i'm writing to be easier to read but much harder to understand and run from a package management perspective. I think the developers working on solutions in JS would probably behave very different if they were given more built in tools to work with.
- paulmd 5y ago
  the same is true of java - less so in newer versions, but older versions the stdlib was pretty slim and low-level and there was a massive amount of library code written to wrap around it. it still doesn't devolve to the javascript phenomenon of one-file (or one-function) libraries and so on. Dozens of libraries, sure, hundreds, maybe, but nobody actually has thousands of dependencies like you do on node. Apparently "number of repos maintained" is a KPI so there's some gamesmanship there. Maybe it's also being used as a caching thing, smaller files might be more cacheable if you don't minify? More generally though this may be the result of that "enterprise culture" that is sometimes looked down on in other situations, that at least stuff is getting bundled into appropriate packages for distribution vs just chucking every single file into a node package.
ratww 5y ago
The problem in Javascript is localized. Lots of extremely important foundational packages like React, Vue, Typescript, and even ones like Prettier don't really have lots of dependencies. The biggest culprits of the craziness are things like Babel and Webpack, which require tens or sometimes hundreds of packages for a basic install. Some of those aren't really needed in Python, for example. But in JS there are alternatives to them. On the other hand, some foundational packages in languages like Python and Ruby have a lot of dependencies. I don't know about Python much, but Rails also has a large dependency graph, despite Ruby having a good standard library.

forty 5y ago

Exactly, I'm not sure what people are trying to fix here. They want code they import in their projects to be sandboxed so they import untrusted code. That seems a bit f*cked up to me. Running untrusted apps is already pretty hard, running apps where some code is trusted and some not, seems... a bad idea. IMO since the problem is generic to all languages we should have a generic solution, using standard sandboxing technics (containers, VMs, jail, etc)

gwright 5y ago
Makes me think of Plan 9 and its almost religious use of the 9P protocol to control what resources are available to a process. Or perhaps the Erlang VM with communication via messages. Composing systems in this way is very different than adding untrusted code to your application but seems like an interesting alternative approach.