Has Deno Turned a Corner?
Deno is NodeJS reinvented. I like writing code for Deno, and I depend on it as a sandbox for Dropserver after trying many other approaches.
I posted this on Mastodon last February: Deno’s mindshare in 2021 was in the single-digits and had only improved by one percentage point a year later. Yikes! Not a good place to be.
See State of JS 2020 survey results and State of JS 2021 survey results.
Why would people not make the switch? I think there are two reasons:
Most legacy code does not run on Deno. Deno is taking a clean sheet approach, and shunning the old Node Package Manager. It’s also all in on ESM modules, while most Node code is CommonJS. So the legacy code is (was) largely incompatible. For developers who are used to finding just about anything on NPM, looking for packages on deno.land/x/ must be a disappointment. For developers of large projects, such as Vite’s Evan You, doing the work to support Deno was simply unthinkable.
Furthermore, while Deno is an improvement over Node, it’s not revolutionary. I remember hearing Ryan Dahl (Node and Deno creator) talking about the early days of Node. He said people would just show up and write packages as they needed them, which quickly filled the void. However this time it’s different. When Node came out, it really stood out. There was nothing like it. Developer experience on most other platforms of the time was poor. So naturally developers did what developers do: they went to town and built it all.
Today there are plenty of fantastic platforms and Deno is not a sufficiently revolutionary step for developers to drop everything and write the libraries that are needed. It’s easier to just stick with Node.
What is Deno doing about it?
The Deno core team seem to have realized that the ecosystem is growing slowly and that the easiest way around that is to make it possible to use NPM dependencies in Deno projects. They’ve taken a multi-pronged approach to the problem: from transforming library CDNs to a compatibility mode in Deno itself. It’s a little messy but at least it’s now possible to use many of the code that assumes Node is the runtime.
Today I see reason for hope
I keep seeing hints that Deno is being embraced by the JS community. I don’t know if what I’m seeing now is the result of the NPM compatibility effort or if there is something else. It could just be that a good project that hangs around long enough eventually gets some uptake.
I saw a tweet the other day showing that Deno can build a Vite project. That’s a big deal. Remember the link above to a comment by Evan You saying it was too early to support Deno? It turns out it’s the Deno devs who made most of the effort to get Vite running, but that doesn’t matter. With Vite functional in Deno, all the dependent projects are suddenly much closer to supporting Deno. Many more good things can happen.
While researching the above, I found that Astro.js, a new better Static Site Generator with Server Side Rendering capabilities, officially supports Deno as an SSR runtime. This time it looks like it’s the Astro devs who put in the effort which shows devs backing Deno with their sweat and blood (OK, maybe not blood, not yet at least). It’s one thing to say “Deno looks cool”. It’s a different matter to release official support for Deno with libraries and docs.
I just learned that Supabase, a well funded and growing alternative to Firebase, chose Deno for its Edge Functions. Again, more developer awareness and commitment already on display from the Supabase devs. It adds to the growing list of platforms that have built-in integration with Deno, such as Slack and Netlify. Anybody who wants to write functions for these platforms becomes a Deno developer.
None of these are significant events, but to me they show a trend that will only build in the future. They make me optimistic. Will the 2022 JS survey show an uptick of Deno developers? Time will tell, but I expect it will. I think Deno is turning the corner.