Hacker News Reader

Comment by redox99 | Hacker News Reader

You can migrate off deno in a single day. It's not a big deal.

Exactly that. I am really surprised by the amount of comments with this huge sentiment and doom mongering. These days it’s really not a big deal. Million lines of deno based ts is not a problem because pretty much any functionality provided to deno is available for node as well. You probably can migrate off much of the external deps without much hassle. You can even migrate to different language ecosystem altogether like others have mentioned in comments.

> ...pretty much any functionality provided to deno is available for node as well.

Unfortunately Node still can't do something like this out of the box (AFAIK at least):

    import { Bla } from "npm:bla@^5";

Such direct imports are basically the killer feature of Deno for simple standalone tooling scripts in otherwise non-JS/TS projects, e.g. it made TS a perfect replacement for Python even without a "batteries included" standard library.

Deno also has a builtin TS type checker, linter, formatter, test runner with coverage support, package manager, language server etc etc... In node these are all separate (and often 3rd-party) tools.

This doesn't seem like a big deal. Don't you just npm install whatever you need and then change the import names?

I don't want the install step. That's redundant. Just a .ts script I can run via `deno run bla.ts` and which directly pulls in any dependency it needs from the web.

Is it?

It's a different mental model I'd say. Specifically: First, I add the part to the pile, then I wire it up.

I wouldn't call it redundant to explicitly spell out what actually happens. If anything, I'd call it good to remind people that they are adding something into their scope of responsibility.

There are use cases like small scripts where people just want a single js file. So the top of that file basically functions as the package.json.

Bun has auto-install for you, but you do have to enable it.

Deno's is slicker. Deno's built-in LSP works with the automatically installed package's types.

I understand the point of this, just saying an existing codebase importing things this way doesn't seem all that hard to convert if you need to get off Deno.

> and which directly pulls in any dependency and exploit

Fix't it for ya.

You can pin versions. If you aren't, you have the same issue with regular npm.

> You can pin versions.

You can, but you won't. Let's be real for a second now - the only reason you use this feature is because you can't be bothered to use a real package manager that pins versions.

The reason is if you have a small script as a single js file and don't want a separate package file and build step. The given example was ^5, same effort as =5. I guess you can also import different versions in different files?

No, version pinning is a lockfile that has verified hashes of git revisions.

Well, nobody is supporting that any more. So you either support it yourself or stop using it.

That wasn't the question though

this one is actually a bad pattern to avoid.

If we were talking in the context of large TypeScript projects, you would be right. Central management helps the project avoid adding too many dependencies.

But you replied to a comment that said "for simple standalone tooling scripts in otherwise non-JS/TS projects" where this absolutely is not a bad pattern.

Only when you have no control over the version you're pulling in, but the semver resolution works as expected. Also we're talking about small standalone 'shell scripts', not 'real projects'. Think 'bla.sh', just with a .ts extension. Deno is really great for such small helper scripts.

> Also we're talking about small standalone 'shell scripts', not 'real projects'. Think 'bla.sh', just with a .ts extension. Deno is really great for such small helper scripts.

Okay. Now I'm confused and my head hurts. You want to randomly download dependencies for a "shell script" at the time of invocation?

I think I need to lie down.

Please explain what exactly is the problem with installing dependencies on demand compared to an 'npm install -g bla', 'brew install bla' or 'apt install bla'? It requires exactly the same amount of trust and is the the same thing under the hood, just that it happens automatically on first invocation of a script.

It's not just about trust.

I wouldn't want a shell script to have side effects aside from its desired function.

On top of that, I wouldn't want a shell script that is being used for some task to have a runtime dependency on Internet connectivity, a registry being up, and/or the chance that a version of a dependency that is used is dependent upon when the artifact was first run.

Then put shell function to your globals which will mimic install + run. It’s literally like 5 minutes of work max and you’ve spent way more arguing over it already.

Nobody says Deno is not better overall than Node. It clearly is, across the board. And nobody cares.

If Deno would provide actual improvements people would care about then for sure it would survive. The problem is that it didn’t. It was just fun project and creators learned a lot for sure. And entire js ecosystem improved thanks to Deno’s push.

FWIW, almost this exact syntax for imports (without the `npm:` prefix) is supported for standalone scripts with Bun.

Bun is not an alternative, it was also acquihired and will probably become an internal project of Anthropic for claude code.

Node only has experimental permissions support (making it not as good for local scripts), and no WebGPU (though you can import dawn wrapper). Deno desktop is way ahead of anything available for Node.

what other runtime has runtime security features?

It's one of those things that the technical aspect is simple but the paperwork dehumanizes me. Just a couple more bullshit engineering design documents to generate

And this is why deno is exiting.

There's no business here anymore.

Exactly. Probably an hour if you just tell your model of choice to do it for you and implement a logical testing framework.

Not really. Tons of platform lock in Apis, Deno.serve, KV etc..

You can't just switch over to nodejs

I don't use KV, but I doubt it's hard to migrate to another key-value store.

Deno has tons of browser APIs, e.g. Deno.serve uses the standard Request and Response objects. That's not platform lock in.

It requires a rewrite and to migrate production systems away from it. Its not a small task.

Reply on news.ycombinator.com