Hacker News Reader

Comment by bartlomieju | Hacker News Reader

There's nothing preventing you from still using a central repository (or its mirrors). I highly recommend "Deno is a Browser for Code" by Kitson [1] which discusses this subject in more depth.

[1] https://kitsonkelly.com/posts/deno-is-a-browser-for-code/

View on HN

Hmm I don't find this article very convincing. From my perspective this is a security and sysadmin nightmare (for the reasons in my link above). Lockfiles actually provide repeatable builds almost all the time, the only times they fail are when depending on non-JS builds like node-gyp or other C++/etc dependencies where you can't lock on system build tooling versions because they're outside the scope of what npm can lock.

The real appeal of Deno for our org is the stdlib, which as a side effect means we can depend on fewer packages. The wholesale removal of the package manager seems like an unwanted pain that will only keep us away from switching and gaining the stdlib benefits.

You are still not thinking of it as a browser. Consider a use case where Deno is the client, not the server. One example is a replacement for piping random curls into bash:

deno run --allow-write=~/.myapp https://myapp.io/install.ts

It works quite well as secure scripting runtime.

I mean that's a neat feature and all, but my primary use for Javascript/Typescript is to write frontend and backend code using the tens of millions of lines of useful library code available in the existing JS/npm ecosystem.

It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement, but there's deliberate friction designed into the system here to try and push people away from node_modules? The upshot of that choice is that I'm unlikely to switch to Deno until that's changed (and I suspect that's the case for many other companies as well).

I love the direction the node compatibility layer is going in though https://deno.land/std@0.80.0/node, now I just wish it supported normal import statements from node_modules (not just require()). I'm quite excited about Deno overall, just waiting for it to get to drop-in point.

> It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement

The 1.0 announcement post the team mentioned:

> For some applications Deno may be a good choice today, for others not yet. It will depend on the requirements. We want to be transparent about these limitations to help people make informed decisions when considering to use Deno.

and:

> Over time, we expect Deno to be able to run more and more Node programs out-of-the-box.

I don't think they've ever claimed to be an immediate drop-in replacement.

Here's a quick example of how to use import maps to get Node-like imports for ES modules distributed on NPM like lodash-es: https://gist.github.com/MarkTiedemann/4ac5837195f52d24bb1dec...

I know I sound like a broken record at this point, but wouldn't it be helpful if Deno just built something like this in automatically to make those import maps given a lockfile:

https://www.npmjs.com/package/@import-maps/generate/v/0.1.0

This way you'd get both the benefits of web standards compliance with the generated explicit import maps, and backward compatibility and ease-of-migration for npm/yarn users.

Reply on news.ycombinator.com