I was runtime/ecosystem hopping recently, trying to find a something that'll make me more comfortable in building RESTful crud + auth services.
I (tried) buildinv the same service in Go, Node(Fastify), Deno(Hono) and Rust (Axum).
Honestly my worst experience was with Deno. It's being built and shipped so fast even the fragmentation doesn't make sense. Some packages are on JSR and others on their own registry. Some NPM packages could be found on JSR but they'd be very out of date, locating docs was very difficult for those individual packages. The new deno.json format was very confusing, was it opt-in or wasn't it. Compatibility may have been fixed but I couldn't get too far with building because of the difficulty in finding upto date packages. They abandoned their own postgres client, which isn't on JSR either.
Now compare that with Rust, which doesn't have anything in it's std-lib to help you connect to a database, setup an HTTP server. However the ecosystem is cohesive enough, maybe partly due to tokio, that you could stumble your way to a recently/library maintained example project on GitHub.
At the end of it I honestly did not see much of a benefit to my development experience shifting to Deno. Projects where I could see some of those devex improvements are too large to migrate.
huh, I mean idk experiences differ. My main project's service is written in Rust/Axum, and I enjoy it a lot. But I thought it was actually kind of frustrating to find that combination; Axum was the 3rd http client I tried, after the first two failed me in different ways. If I had started with the https client first and hadn't already felt good about building the codebase in Rust, I might have just gotten annoyed and moved on. First impressions can sometimes skew the perspective a little.
fwiw, re finding up-to-date packages, you can also pull in npm dependencies. idk what you found confusing about the deno.json, but it's definitely optional; you can just write imports directly in the .js file if you want. I often make single-file scripts to run some npm package over a local file.
That's the issue, Deno wasn't my first impression of typescript for the backend. Every decision I was took, there was a voice in the back of my head whispering, "it's probably easier on node". Not the actual code, but getting information about how to actually achieve those things.
The problem with making something as important as a package file optional it makes it very confusing for new users to get started because a variety of tutorials and getting started guides end up having a lot variation between them.
I mean... I find deno.json-less scripts to be incredibly convenient for creating single-file scripts, and I've found deno configuration to be pretty clear. You're not wrong for disliking Deno; it has opinions, and those can turn people off. But I happen to find those opinions and decisions to be quite convenient and useful for me.
How would you rate the rest of the items in this experiment? Could you rank them based on "pleasure to work with", speed, stability, suitability for large projects, etc?
I (tried) buildinv the same service in Go, Node(Fastify), Deno(Hono) and Rust (Axum).
Honestly my worst experience was with Deno. It's being built and shipped so fast even the fragmentation doesn't make sense. Some packages are on JSR and others on their own registry. Some NPM packages could be found on JSR but they'd be very out of date, locating docs was very difficult for those individual packages. The new deno.json format was very confusing, was it opt-in or wasn't it. Compatibility may have been fixed but I couldn't get too far with building because of the difficulty in finding upto date packages. They abandoned their own postgres client, which isn't on JSR either.
Now compare that with Rust, which doesn't have anything in it's std-lib to help you connect to a database, setup an HTTP server. However the ecosystem is cohesive enough, maybe partly due to tokio, that you could stumble your way to a recently/library maintained example project on GitHub.
At the end of it I honestly did not see much of a benefit to my development experience shifting to Deno. Projects where I could see some of those devex improvements are too large to migrate.