Deno 1.20

Not switching from Node, but I've been building some Typescript libraries that are mainly for the browser and when building command line app versions for them, Deno worked out of the box while Node has hiccups (no Fetch, no Websockets, etc) and since Deno works so well I just never added Node support.

Small aside: if you ever plan on doing Deno-first libraries, https://deno.land/x/dnt@0.20.1 is a library that takes a Deno project and builds an entire Node project with shims (sadly only for Deno-specific stuff, so no node-fetch or ws) so you can publish to NPM.

It's a pretty ergonomic way of scripting smaller tasks, at least. The first time picked it up for the sake of a meaningful experiment I stopped short of actually deploying a full project on it -- the key limitation being that I couldn't find anything comparable to Mongoose -- but did end up building a companion tool that turned out to be pretty useful, and for stuff like API calls and bulk file manipulation I would reach for it every time.

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.

I love working with JS/TS (front, back, tooling), but find Node more and more annoying (especially bothered with packaging a release for production, lately).

So naturally I tried Deno lately.

Some things mentioned in other comments were really nice, but the lack of retrofit with the Node ecosystem is a shame. So many years and efforts and community growth are sitting right next door only to be ignored...

I can't understand that.

Looks promising and I find the Deno project very exciting!

What is the recommended way of running Deno in production on a multi core machine? In node there is the cluster module that allows one process to run a cpu intensive task while the other processes to continue answering web requests.

This is good for stuff like excel exports as an example on larger datasets. Obviously you could run some kind of cronjob in the background but it seems like I may a bit confused about Denos architechture regarding this subject. I am afraid of switching to Deno because of this since I often want to do these kind of operations without having to do the hassle of breaking the app up for simple exporting/importing operations.

Also, will Deno really utilize other cores on the machine? It seems like if you have a machine with multiple cores Deno won't use the full potential of the hardware or am I just confused about this subject?

What is the reality of Deno now?

I remember when Deno was being developed it was promoted like how Web3 is being promoted right now. But browsing through hundreds of job posts I have not seen anyone having Deno as a requirement. Everyone wants Typescript+Node and that's about it.

Size of community, enterprise use and approachability as the first framework to learn. I think these 3 factors determine the success of any programming related stuff. Performance on the other hand is what people talk about. But nobody cares about performance irl.