Earlier this year, we published a survey to help focus our efforts on improving the Deno runtime. With over 700 responses (thank you to those who filled out the form!), we gained some valuable insight into the progress we’re making, as well as identified which areas need improvement.

Here’s the high level summary of the key insights gathered from the survey, as well as where we’re focusing our efforts ahead of Deno 2:

• Our Node/npm compatibility has come a long way
• Framework compatibility is also important
• Host Deno anywhere
• A major upgrade to dependency management
• Road to Deno 2

Check out the results in JSON format here.

Our Node/npm compatibility has come a long way

It’s understandable that not being able to access key npm modules or run Node projects can be a non-starter for some folks when it comes to using Deno, which is why we have spent a tremendous effort in improving Node and npm compatibility. The good news is that the majority of respondents in the recent survey indicated that Deno was already well on its way to becoming their default runtime for all projects, based on the existing level of compatibility. However, the results indicated that we have further to go on this front until we’re satisfied.

In the next few months, we’re hyper focused on improving Node and npm compatibility, specifically around:

• identifying and fixing bugs
• landing additional Node API polyfills

Our goal is to make any npm module work with Deno, while also eliminating a lot of frustration around using npm with Node. We aim to provide an overall better developer experience, through reducing config files and steps around dependency management.

Framework compatibility is also important

Aside from being able to use Deno to access npm modules, we asked about the importance of running third-party frameworks. Around 80% of respondents indicated that third-party framework compatibility is essential to their work.

While most expressed no issues with using third-party frameworks with Deno, a subset indicated they ran into friction points, so we’re making third-party framework compatibility a top priority in 2024.

While many frameworks are already supported with Deno (such as React, Express.js, Qwik), we acknowledge that some aren’t fully supported or have a less than ideal developer experience when using with Deno. We’re determined to improve framework compatibility to ensure a best-in-class developer experience ahead of Deno 2, such as supporting Next.js.

Host Deno anywhere

Using Deno to build servers and APIs remain a top use case, so it’s no surprise that many are hosting Deno in the cloud. We’re happy to learn that nearly half of respondents selected “Strongly Agree” when asked whether it was easy to host a Deno project in the cloud.

So where are most users hosting Deno projects? Over 50% are hosting them with Deno Deploy, our globally distributed v8 isolate cloud, but we also see meaningful usage in other cloud providers.

The top cloud providers for hosting Deno projects.

Other cloud hosting providers for Deno mentioned include AWS, Vercel, GCP, and Digital Ocean. While we have tutorials on hosting Deno with deno_docker to VPS hosting providers, we recognize there’s more to do to ensure a smoother end-to-end self-hosting experience.

To that end, we’ve recently added Arm64 Linux support and became active maintainers of deno-lambda to create Docker images for AWS Lambda. In the upcoming months, we’re focused on creating:

• best practices for building Docker containers for various Deno apps
• guides for writing Deno services on AWS ECS and Lambda, with CloudFormation/Terraform templates

Running into issues with hosting Deno or need some guidance on how to host Deno for your project? Let us know here.

A major upgrade to dependency management

Deno launched with a radical idea of URL imports, which is how browsers operate. On paper this made sense. But we ran into issues — what if a program contains two modules but of different versions? Reconciling this on the module graph is a complex engineering issue, known as the Duplicate Dependency Problem. We’ve developed patterns like deps.ts to manage remote dependencies. But this is still suboptimal, requiring flattening and re-exporting necessary symbols, leading to a more verbose and cluttered version of package.json.

Many survey respondents agreed that dependency management can be improved, leaving comments asking for best practices around managing dependencies, de-duplicating transitive dependencies, updating dependencies, to name a few.

Dependency management is still painful and we’re working hard on a solution we hope can benefit the entire JavaScript and TypeScript community — a modern registry built on web standards.

Road to Deno 2

We’re grateful for an active community eager to give us feedback and improve Deno to become the default JavaScript and TypeScript runtime. The results from this survey not only indicate strongly that we’re on the right path, but also helps focus our efforts on features important to you.

We’re targeting a major version release this year, which will offer third party framework compatibility, the ability to use any npm module, all while having a best-in-class developer experience.

Questions? Comments? Let us know on Twitter or Discord.