Hacker News Reader

Comment by maga | Hacker News Reader

I have moved all my library development to Deno and described the experience in a blog post[1].

To summarize, the two killer features for me are Web APIs and the built-in toolchain.

I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My last straw was trying to run Jest tests on TS code compiled into a Node.js ESM module. I believe I spent more time figuring out workarounds for a myriad of issues in Jest+ Node+TSC chain, than it took me to switch to Deno where all of it came out of the box.

[1] https://itnext.io/moving-libraries-to-deno-the-whys-and-hows...

edit: spelling

View on HN

thanks for posting this. Much needed. When you said: > The process of reconciliation has been slow and painful, cue ESM modules.

I too have run into the similar issues when trying to use JS isomorphically. Especially in combination with typescript. Just wonder how Deno is addressing this? For example: when es import for module server side, in typescript it is ok to omit the file extension, (in typescript development mode it is expecting .ts files), however that breaks when the same code is run on the client side or production mode when it is tsc. How is Deno dealing with this issue? Does Deno just compile all the code to work in broser, serverside typescript all together?

Yes, TS code is compiled to run in browsers. You can compile and bundle using `deno bundle` if your project is developed in Deno. Since I'm using Deno for library development, I use the `dnt`[1] tool to compile them into ESM modules later consumed by esbuild in my Node-based projects/toolchains.

[1] https://github.com/denoland/dnt

To be fair we have most web APIs that Deno has in Node with the exception of some we probably don't want to have. Namely: stuff like URL, fetch, AbortSignal, EventTarget, BroadcastChannel and a few others.

We can still appreciate that Deno puts some "pressure" on Node to continue improving and to copy any good idea Deno might introduce, which is a net win for everyone, even if most people continue using Node.

I simply loved that `prompt` works in Deno. Such a simple API! I don't need to evaluate multiple npm packages to see which one works better for me.

WebWorker may be one of the most important ones missing in Node.

I was a little confused at first, but I think you mean “killer features”. “Killing features” is not idiomatic, and has kind of the opposite (i.e. negative) connotation

Good catch, thanks!

Reply on news.ycombinator.com