8 ms·

I don't think that the same community producing huge quantities of single use libraries for the sake of padding their resumes will get involved with sandboxing.

I don't think that the same community producing huge quantities of single use libraries for the sake of padding their resumes will get involved with sandboxing. I recently installed a relatively simply piece of software using NPM and was stunned when it downloaded hundreds dependencies from god knows where, there's simply no ability for anybody to ever evaluate the security risk of NodeJS applications. https://npm.anvaka.com/#/view/2d/zigbee2mqtt https://npm.anvaka.com/#/view/2d/zigbee2mqtt

7373737373 6y ago
Then perhaps single use libraries should be limited to 'computation only' by default :)
Chyzwar 6y ago
This module use widely used packages in node. In any non-trivial node project you would already have these. Whole point of small single use packages is to prevent from re-inventing a wheel. People are bashing node community without understanding. Typical you would have people publish hundreds similar packages to solve a specific problem. Over time, best maintained, feature complete would "win" and become a standard, at this point other packages would converge and use these 1/2 top solutions. This process allow exploring large space of possible solutions and prevent app developers from NIH. There is more churn, but also more innovation and productivity. See for example css-in-js evolution story. https://www.youtube.com/watch?v=75kmPj_iUOA https://www.youtube.com/watch?v=75kmPj_iUOA
cxr 6y ago
> there's simply no ability for anybody to ever evaluate the security risk of NodeJS applications So don't. Tell people that you're not going to run their NodeJS crud and let them know it would be better to write their scripts wherever possible to be able to run on the sandboxed JS runtime that everyone already happens to have installed: the browser. https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646
- IggleSniggle 6y ago
  I really like this idea, but it misses the appeal of nodejs and its ilk...that you can speak the same JSON-native language on the backend as the front. I think it’s a VERY interesting idea to use a browser for running some tooling, but that’s really just what the idea behind nodejs and deno etc are, aren’t they? It’s just that node tries to be convenient by providing access to things that would need in a non-user context (like filesystem and C interop), thereby breaking the sandbox. Deno tries to give you the best of both. Running this stuff in the browser is still “just running on V8”, but with extra steps. If you don’t like the npm ecosystem, I get it, but then running nodejs without any packages is comparable to what you’re describing in the link, isn’t it?
  - cxr 6y ago
    > that’s really just what the idea behind nodejs and deno etc are, aren’t they? Yeah, I guess they're pretty much the same thing, except for all the stuff I mentioned. > Running this stuff in the browser is still “just running on V8”, but with extra steps. I don't know what this is supposed to mean. I don't know where this quote comes from, or what it's even trying to say. Nobody starts out with a computer with NodeJS and Deno installed and then has to go install a browser. Everyone already has a browser, on the other hand, and it's standardized and forward-compatible by design/commitment. From that perspective, NodeJS and Deno are '"just running on V8", but with extra steps' (truly—V8 exists for the Web browser and has only incidentally been lifted out and made to drive NodeJS, too—after a lot of contortions). > you can speak the same JSON-native language on the backend as the front Huh? Not only does this not make sense, but the backend appeal of NodeJS is completely irrelevant in matters of metatooling, aka "devDependencies" in NodeJS terms.
IggleSniggle 6y ago
It looks like the library you are referencing touches lots of different proprietary hardware? While I agree with your overall point, a “universal wrapper” for lots of different things is exactly the sort of thing I would expect to have dependencies from who the heck knows where.

7373737373 6y ago

Then perhaps single use libraries should be limited to 'computation only' by default :)

Chyzwar 6y ago

This module use widely used packages in node. In any non-trivial node project you would already have these. Whole point of small single use packages is to prevent from re-inventing a wheel. People are bashing node community without understanding. Typical you would have people publish hundreds similar packages to solve a specific problem. Over time, best maintained, feature complete would "win" and become a standard, at this point other packages would converge and use these 1/2 top solutions. This process allow exploring large space of possible solutions and prevent app developers from NIH. There is more churn, but also more innovation and productivity. See for example css-in-js evolution story. https://www.youtube.com/watch?v=75kmPj_iUOA https://www.youtube.com/watch?v=75kmPj_iUOA

cxr 6y ago

> there's simply no ability for anybody to ever evaluate the security risk of NodeJS applications So don't. Tell people that you're not going to run their NodeJS crud and let them know it would be better to write their scripts wherever possible to be able to run on the sandboxed JS runtime that everyone already happens to have installed: the browser. https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646

IggleSniggle 6y ago
I really like this idea, but it misses the appeal of nodejs and its ilk...that you can speak the same JSON-native language on the backend as the front. I think it’s a VERY interesting idea to use a browser for running some tooling, but that’s really just what the idea behind nodejs and deno etc are, aren’t they? It’s just that node tries to be convenient by providing access to things that would need in a non-user context (like filesystem and C interop), thereby breaking the sandbox. Deno tries to give you the best of both. Running this stuff in the browser is still “just running on V8”, but with extra steps. If you don’t like the npm ecosystem, I get it, but then running nodejs without any packages is comparable to what you’re describing in the link, isn’t it?
- cxr 6y ago
  > that’s really just what the idea behind nodejs and deno etc are, aren’t they? Yeah, I guess they're pretty much the same thing, except for all the stuff I mentioned. > Running this stuff in the browser is still “just running on V8”, but with extra steps. I don't know what this is supposed to mean. I don't know where this quote comes from, or what it's even trying to say. Nobody starts out with a computer with NodeJS and Deno installed and then has to go install a browser. Everyone already has a browser, on the other hand, and it's standardized and forward-compatible by design/commitment. From that perspective, NodeJS and Deno are '"just running on V8", but with extra steps' (truly—V8 exists for the Web browser and has only incidentally been lifted out and made to drive NodeJS, too—after a lot of contortions). > you can speak the same JSON-native language on the backend as the front Huh? Not only does this not make sense, but the backend appeal of NodeJS is completely irrelevant in matters of metatooling, aka "devDependencies" in NodeJS terms.

IggleSniggle 6y ago

It looks like the library you are referencing touches lots of different proprietary hardware? While I agree with your overall point, a “universal wrapper” for lots of different things is exactly the sort of thing I would expect to have dependencies from who the heck knows where.