It looks like Ryan Dahl predicted it: "It would be nice to download the massive codebase that ESLint is and run it without it taking over my computer - which it could."
Sandboxed by default is the best design decision of deno.
Using URLs for import is another one. npm as a company has too much power and responsibilities that is really unnecessary. We're downloading from a URL anyways. package.json and npm makes it look like everything has to be hosted there
Cargo packages can also execute arbitrary code at compile-time through build scripts, which run with full permissions of the original `cargo` command including filesystem and network access.
Just to be clear, the reason I (and others) use the NPM registry is that it saves us a ton of time and helps us be more productive.
There is nothing stopping me or you from putting "regular" JavaScript files in your `node_modules` and `require`ing them or running node with ESM and a loader that loads URLs (requires Node 10) and have the same semantics as deno with packages.
Some problems I personally see with URLs is versioning (and versioning of dependencies) and the fact it's harder for multiple packages you're using to have the same dependency without downloading it twice.
productive... sorry but I'm starting to hate this word. What do you mean by that? Being able to randomly import blobs of code that maybe does something that might help you as you go figure out what you're supposed to implement while at the same time the "customer" is also figuring out what they want?
So a few things - now that this won't get any more 'public' attention.
> What do you mean by that?
Compared to the alternative (of manually importing code) it saves me time. The 'download code from the internet' problem isn't new to NPM or new to package managers or even related - it is orthogonal in my opinion.
> Being able to randomly import blobs of code that maybe does something that might help you
I usually know exactly what the code I'm using does and why I'm importing it.
> you go figure out what you're supposed to implement while at the same time the "customer" is also figuring out what they want?
This lights up a bunch of red lights to me. This is nothing like the development process I know. I strongly suggest you consider looking for a place that doesn't treat developers like that (mostly technical companies tend to be better in this regard).
It is a programmers' market and you get to choose a workplace with good culture. The path of feeling like your goals are unclear or unimportant while caring about them leads to burnout. Stay strong :)
(
> Argh, please! What a crazy asylum...
FWIW, I think the mental health reference is in bad taste.
)
Using URLs for import is another one. npm as a company has too much power and responsibilities that is really unnecessary. We're downloading from a URL anyways. package.json and npm makes it look like everything has to be hosted there