2 ms·

> I’m eager to use Deno more, there’s a lot that appeals to me more than Node. Like what? I’m genuinely curious.

eyelidlessness 5y ago
1. Its API tends to be much closer to browser/web standards. This appeals to me because it’s easier/more productive to learn and reference one thing than multiple, similar things. It also appeals to me for portability, and potentially large improvements for “isomorphic” UI. 2. TypeScript in ESM is supported out of the box without a build step. There are solutions to this in Node, but they all have trade offs: ts-node is correct, but slow; ESBuild solutions are incorrect/incomplete (both because ESBuild itself lacks some TypeScript features and because the ESM loaders miss a variety of edge cases; ESM loaders are still experimental and there are large API changes coming in Node 17 (and presumably Node 18 which will be in LTS alongside the older APIs). 3. Performance: in terms of TypeScript (Deno uses SWC, which is nearly as fast as ESBuild and IIRC more correct), as well as heavy investment in Rust internals and third party extensibility. 4. Package management is both more standard (just import URLs) and more flexible (built in support for import maps, etc). 5. Related to #1 and #2, but a separate point: Deno can be expected to evolve faster while remaining relatively stable. Node has many legacy APIs that will likely never be deprecated in favor of even the standards it does adopt, and supporting those APIs already makes adopting newer standards more challenging. 6. There’s something refreshing to me about the fact that Deno’s creator was also Node’s, and that Deno is explicitly an admission of mistakes/warts in Node’s original design.
- rpastuszak 5y ago
  That's a great overview, thanks! The only thing missing for me here is having a permission model similar to WASI, where we could potentially have sandboxing per module/dependency. IIRC in Deno this is done on the application level. I wish it was a bit more granular. I'm not too fussed about esbuild not supporting TS as well as SWC does, e.g. I don't care about enums. But your comment made me realise that I should probably give it another shot. Cheers

1. Its API tends to be much closer to browser/web standards. This appeals to me because it’s easier/more productive to learn and reference one thing than multiple, similar things. It also appeals to me for portability, and potentially large improvements for “isomorphic” UI. 2. TypeScript in ESM is supported out of the box without a build step. There are solutions to this in Node, but they all have trade offs: ts-node is correct, but slow; ESBuild solutions are incorrect/incomplete (both because ESBuild itself lacks some TypeScript features and because the ESM loaders miss a variety of edge cases; ESM loaders are still experimental and there are large API changes coming in Node 17 (and presumably Node 18 which will be in LTS alongside the older APIs). 3. Performance: in terms of TypeScript (Deno uses SWC, which is nearly as fast as ESBuild and IIRC more correct), as well as heavy investment in Rust internals and third party extensibility. 4. Package management is both more standard (just import URLs) and more flexible (built in support for import maps, etc). 5. Related to #1 and #2, but a separate point: Deno can be expected to evolve faster while remaining relatively stable. Node has many legacy APIs that will likely never be deprecated in favor of even the standards it does adopt, and supporting those APIs already makes adopting newer standards more challenging. 6. There’s something refreshing to me about the fact that Deno’s creator was also Node’s, and that Deno is explicitly an admission of mistakes/warts in Node’s original design.

rpastuszak 5y ago
That's a great overview, thanks! The only thing missing for me here is having a permission model similar to WASI, where we could potentially have sandboxing per module/dependency. IIRC in Deno this is done on the application level. I wish it was a bit more granular. I'm not too fussed about esbuild not supporting TS as well as SWC does, e.g. I don't care about enums. But your comment made me realise that I should probably give it another shot. Cheers