I had a very similar reaction at first (the exception being first class TypeScript support). I’ve since come around to being very interested in Deno and curious to use/support it more. Here’s what’s brought me there:
- As I’ve adopted ESM, I’ve found Node’s ESM support difficult to deal with. Deno being ESM by default is a huge improvement, and makes portability to other environments much easier.
- TypeScript isn’t just supported, it’s very fast! Much faster than solutions like ts-node. Not limited/incomplete like current esbuild-based ESM loaders (though I’m actively working on solving that for Node).
- Async APIs are all Promise-based. No legacy sync/callback/promisify.
- Import maps allow complete flexibility with dependencies: you can use NPM or another package manager if you really want. You can customize package management however you prefer. You can completely sidestep NPM audit hell.
- The standard library is good actually! And it’s ESM so it’s immutable by default.
- Quite a lot of stuff that requires build tooling (eg isomorphic web) is not needed server-side at all. But I was curious about your questions about Babel/Flow and it looks like there are APIs that allow you to customize compilation if you need to.
The module stuff is what has me looking at it. We’ve got a bunch of Node services that are relatively small and single purpose. Using tsnode, adding a build step, tinkering with ESM/CommonJS to work within the monorepo TS project reference graph... it feels like a huge PITA with mostly unnecessary overhead.
Basically... we’re a “TypeScript native” project from day zero... so why do we need to be weighed down with all this cruft from historical JS ecosystem decisions? I’m planning to try swapping one of these services to Deno to see how much easier it is.
- As I’ve adopted ESM, I’ve found Node’s ESM support difficult to deal with. Deno being ESM by default is a huge improvement, and makes portability to other environments much easier.
- Similarly, Deno’s default deferral to existing JS/browser standards helps portability immensely.
- TypeScript isn’t just supported, it’s very fast! Much faster than solutions like ts-node. Not limited/incomplete like current esbuild-based ESM loaders (though I’m actively working on solving that for Node).
- Async APIs are all Promise-based. No legacy sync/callback/promisify.
- Import maps allow complete flexibility with dependencies: you can use NPM or another package manager if you really want. You can customize package management however you prefer. You can completely sidestep NPM audit hell.
- The standard library is good actually! And it’s ESM so it’s immutable by default.
- Quite a lot of stuff that requires build tooling (eg isomorphic web) is not needed server-side at all. But I was curious about your questions about Babel/Flow and it looks like there are APIs that allow you to customize compilation if you need to.