Why Deno might not be ready for you and what we are doing about it
While we do think Deno isn't quite ready for prime time yet, we are actively working on this by building deno-first modules under the "dunosaurs" github organization.
A statistics / data science library for Deno
A simple and fast typescript diff implementation for Deno
A simple, fast, and comprehensive color library for Deno.
Deno library for converting arbitrary strings into valid slugs
A simple deno text-to-speech library using the google translate api.
A Deno port of chalk's supports-color
A Deno implementation of a nostr client and server.
The fact that this page needs updating is a fantastic sign that Deno is headed in the right direction.
Lockfile should be written by default - Deno now writes lockfiles by default 🎉. This is a great step forward in the world of potential supply-chain attacks.
Deno now does have nearly the module support of node with the release and stabilization of npm specifiers. While the compatibility isn't 100% there, and there are still some issues with the compat layer's implementation of things like websocket and https, it is now perfectly usuable and no longer the huge problem it was.
Deno is currently sluggish in comparison to Node and especially in comparison to something like Go.
According to this article, Deno can handle on average ~25% less requests than Node.
One of the major decisions that Deno made in 2020 signficantly improved this issue by not type checking by default, but the overall performance of developing and running the application leaves a lot to be desired.
With bun.sh taking the performance crown handily. This becomes very important for the future of Deno.
People say this a lot but I want to be a little more concrete about it. One way I find to check really quickly if something is mature is to see what big issues are left to be resolved. I'm going to do a quick list of what issues I consider big and an elevator pitch on why each is imporant.
Remove pure JS (non native) io functions from Deno namespace - The Deno namespace has a few methods that shouldn't be there. Using any Deno namespace call instantly makes your code incompatible with the browser and thus isn't great. Moving any code that *should* be browser-compatible to the standard library would fix this.
Detached processes in deno - Deno can't currently run a child process in detached mode. This is a pretty big oversight but it's niche enough to probably not effect you directly.
Default to h and Fragment for JSX - Deno has not finalized its default tsconfig yet. For a runtime with supposed "first class" support for typescript, this not being nailed down isn't great.
Deno has nearly no Stack Overflow history, especially in comparison to Node.
A search for Deno on SO results in just over 2,000 questions.
In node? Over 1,100,000!
If you have a problem with Deno, there is a very high likelyhood that you will be the first person on the internet with that specific issue.