Hacker News Reader

Comment by konradzikusek | Hacker News Reader

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."

https://www.youtube.com/watch?v=M3BM9TB-8yA&feature=youtu.be...

View on HN

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

URL imports is a terrible idea. There's a reason we have actually package managers and repositories instead of installing from GitHub.

Properly made and run package managers are more secure and offer a better developer experience than importing by URL.

Which package managers are properly made, and how are they more secure? As far as I'm aware npm's security model is shared with almost all of them.

RPM and .deb packages have GPG signatures and lists of trusted maintainers. NPM doesn't have that; https://medium.com/redpoint/introducing-pkgsign-package-sign... looks like a very early start on a big project that could fix this if it catches on.

Cargo is far better in this regard, for one.

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.

> package managers are more secure

How?

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?

Argh, please! What a crazy asylum...

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. )

One of the few things maven got right was explicitly including the semver in a module's path. eg ./root/leftpad/1.2.3/bundle.zip (IIRC)

Reply on news.ycombinator.com