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.
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
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.
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):
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?
5 replies →
FWIW, almost this exact syntax for imports (without the `npm:` prefix) is supported for standalone scripts with Bun.
1 reply →
this one is actually a bad pattern to avoid.
2 replies →
[dead]
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
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?
Exactly. Probably an hour if you just tell your model of choice to do it for you and implement a logical testing framework.
And this is why deno is exiting.
There's no business here anymore.
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.
[dead]