Unless you're writing a totally new application and don't need anything (even retrospectively) from NPM, Deno probably won't work for you.
As much as I like Deno as a concept, I can't really use it. Making a totally new JavaScript runtime with new API's and no compatibility with the current largest runtime is a very ambitious goal, and I hope they succeed with it nevertheless.
Many of the APIs you mentioned are supported already, while a few require the unstable flag...
https://deno.land/std/node/README.md
In my experience I've been able to use many node packages unmodified recently.
Well… the current largest runtime is web browsers and Deno has a much better story there than Node does. But agreed, it’s a long road ahead.
I tried to push through and port one of them, but the base Node Socket library was missing most of the methods.
Deno looks awesome though, I can’t wait to take another look when it’s a little more mature!
Specifically, it was a minimal simfile parsing/conversion/seeding tool, as part of a DDR workout tracker I was working on a while ago. (Everything from COVID to a mouse problem in my workspace kind of undercut me doing the cardio I had built it to track, so it sort of stagnated :-/ But the tooling itself was pleasant enough here.) Basically it had three core pieces of functionality:
- Parsing .sm files and converting them to .ssc (the former doesn't label its fields, so doing this first simplified everything else)
- Extracting metadata from simfiles in .ssc format and exporting it to JSON
- Uploading extracted metadata to the accompanying API
This is something of a moot point since it's been added to Node now, but at the time having access to server-side `fetch()` also saved me some frontend work, because then all of my client-side requests became isomorphic and I could just mock out what I was eventually going to need for my UI without actually having to make any other decisions about how the UI was going to be structured.