Should you switch to Deno?

TL;DR: Considering switching from Node.js to Deno? This article highlights key reasons for the change, explores Deno’s features, and helps you decide if it’s the right choice for your projects.

Co-writers: @florob95 and @bruno.sinteff

For history

In 2018, Ryan Dahl, the creator of Node.js, made an announcement that shocked the developer community. He presented a list of “10 things I regret about Node.js” , highlighting the shortcomings and challenges faced by developers faced with Node.js. These critical points included issues with dependency management, design flaws in the module system, and concerns regarding security and file management. However, Dahl offered hope by introducing Deno, a tool he created to solve these problems. Written in Rust and based on Google’s V8 JavaScript engine, Deno promised a more secure approach, improved dependency management, and a modern architecture for server-side JavaScript development. After an active development period and several beta versions, Deno finally reached its version 1.0 milestone in May 2020, marking a significant step in its evolution and asserting its position as a competitor to Node.js.

But can it really hold its own in the competitive world of production? This article explores Deno’s potential, examining both its advantages and challenges.

So, what are Deno’s strengths?

• Built-in security: Deno follows a “least privilege” approach, meaning that by default, programs don’t have direct access to files, networks, or the environment. This reduces the chances of security vulnerabilities. This security-first approach is a major advantage in today’s threat-filled digital landscape. Node.js has taken cues from Deno’s security model. Deno integrates various security features, such as simplifying tasks like handling httpProxy and httpsProxy. In Deno, this process requires less code compared to Node.js, making it easier and more secure to manage network-related tasks.
• Native TypeScript: Deno directly supports Typescript without additional configuration, simplifying development and ensuring type safety by default.
• All-in-one toolset: Deno provides built-in tools for testing, linting, formatting, and more. This eliminates the need for external tools, streamlining your workflow and allowing you to focus on coding rather than managing toolchains.
• ECMAScript modules (ESM): Deno adopts standardized ESM modules, simplifying dependency management and reducing version conflicts. This approach also future-proofs your code for compatibility with upcoming JavaScript features. By using ESM, Deno provides many built-in tools that work just like the ones you’d find in a web browser. For example, it includes fetch for network requests, and the Temporal API for working with dates and times. These built-in tools make it easier to build web applications with Deno.
• Performance: Under the hood, Deno utilizes the performance and resource efficiency of Rust. While benchmarks vary, Deno offers the possibility of faster performance compared to Node.js, potentially improving application responsiveness and scalability.

Challenges and considerations

While Deno offers a lot of advantages, it’s crucial to consider its current limitations before adopting it for production use.

• Cloud support: Deno currently lacks official support on major cloud platforms like AWS, Google Cloud, and Azure AD. This makes it harder to integrate smoothly into existing cloud systems, which could be frustrating for developers who want everything to work together seamlessly.
• Standard library stability (std)

Deno’s core modules, while offering exciting possibilities, remain in their early development stage, as indicated by the current (0.*). This might suggest that Deno might be focusing more on features like Deno Deploy, Deno subhosting or other stuff rather than fully these essential functionalities? Developers who heavily depend on standardized modules might encounter limitations and compatibility issues due to potential breaking changes.

Evidence of this rapid evolution can be seen through the substantial number of breaking changes (87) implemented in the standard library over the past year. Modules like http and encoding have undergone particularly frequent modifications, averaging one breaking change every three versions. Similar patterns are observed with path (every 4 versions), csv (every 5 versions), and collections (every 6 versions).

These frequent modifications, while indicating active development and potential improvements, can present challenges for long-term project maintenance. Ensuring compatibility with constantly evolving libraries can be time-consuming and resource-intensive, potentially impacting development costs and introducing security risks.

Therefore, while Deno’s standard library show potential for the future, its current state of rapid development necessitates careful consideration of your project’s specific needs and risk tolerance before adopting it for production environments. Carefully evaluating the potential benefits and challenges associated with frequent breaking changes will ensure an informed decision for your development journey.

Here is the table that provides a breakdown of the breaking changes made to the Deno standard library over a one-year period, from 2023 to 2024.

| Version | Breaking changes | Affected Modules                                               |  

|---------|----------------- |----------------------------------------------------------------|  

| 0.211.0 | 6                | Collections, Crypto, Front_matter, Http, Path, Top level types |  

| 0.210.0 | 3                | Crypto, Encoding, Http                                         |  

| 0.209.0 | 7                | Async, Bytes, Collections, Datetime, Fs, Http, Media_types     |  

| 0.207.0 | 8                | Bytes, Crypto, Fs, Http, Cli, Wasi                             |  

| 0.205.0 | 5                | Dotenv, Http, Csv                                              |  

| 0.202.0 | 6                | Collections, Crypto, Csv, Datetime, Media_types, Streams       |  

| 0.201.0 | 10               | Bytes, Crypto, Dotenv, Encoding, Fmt, Permissions, Streams...  |  

| 0.180.0 | 6                | Csv, Front_matter, Json, Jsonc, Toml, Yaml                     | 

Src: github denoland/deno_std releases 

Updated 10/06/2024: Great news! The packages in the Deno Standard Library will be stabilized to version 1.0 soon.

Migration from Node.js:

In the beginning, Deno wanted to do its own thing, separate from Node.js. They used their own way of organizing code, called deno.land, where you could get modules from the internet. They did this to avoid the problems that come with using npm and the node_modules folder.

As time went on, Deno might have realized that many people, projects and companies were already using npm and its vast library of code. Ignoring all of that would be challenging. Developers relied on npm for their projects, and it didn’t make sense to disregard that.

Deno started to focus more on working alongside npm and Node.js instead of trying to compete with them. In 2023, they made significant improvements to help developers migrate their projects from Node.js to Deno more easily.

Deno’s team has recently introduced the JSR, a superset of npm, designed to simplify the handling of code packages. This initiative underscores Deno’s commitment to compatibility with existing JavaScript tools. The JSR aims to facilitate the integration of npm packages with Deno, reflecting Deno’s acknowledgment of the importance of npm to developers. While Deno is begining to transition its packages to JSR, it’s important to note that JSR is still in its early stages of development. We’ll need to monitor its progress to assess its full potential and impact on the developer community.

Even though Deno is improving its compatibility with npm, there are still some challenges. The way Deno works isn’t exactly the same as Node.js, so some things don’t work seamlessly in both environements. However, Deno understands the importance of this compatibility and is working hard to make things smoother for developers. This includes addressing any compatibility issues that may arise when using the JSR.

To make switching from Node.js and npm to Deno easier, consider these steps and features:

• Write code in ESM: Deno supports only ESM, so if the project is written in CJS, it must be rewritten to ESM.
• Using npm: specifiers and node: specifiers. Deno allows you to use npm packages by specifying “npm:”, “jsr:” or “node:” in your code. This allows you to use libraries from npm directly in your Deno projects.
• Ensuring package.json compatibility: Deno supports dependency resolution based on a package.json file, similar how to Node.js resolves dependencies. It is recommended to use import maps with deno.json, detailed here.
• Exploring compatibility through CDNs
• The -unstable-byonm flag This is a really interesting feature in Deno lets you use npm packages directly from the node_modules folder without needing to specify “npm:” in your code. It’s still being tested and experimental, so there may be bugs, but it shows promise for simplifying the transition from Node.js to Deno.
• With the -unstable-sloppy-imports flag, Deno has relaxed the strictness of module imports, accommodating a wider range of coding styles and practices.
• The -unstable-unsafe-proto flag introduces support for Object.prototype.__proto__, a feature upon which numerous npm packages depend.
• The stabilization of the Node-API

While Deno shows potential, a cautious approach is advised for large-scale production projects. It’s recommended to closely monitor Deno’s development and compatibility progress before undertaking a full migration.

Performance comparison

To measure Deno’s compatibility with npm libraries, we created a benchmark comparing Node and Deno using different web frameworks (express and oak).

For this benchmark, we created a server with 3 different routes:

GET /tokens: get all tokens
GET /token/:id: get token
POST /token/:id: create token

In each route, we use middleware for logger and validation. Tokens are stored in the Redis database and each request implies Redis operations.

Our results can be seen below:

The test on MacOs Intel: Node version: 20.9.0 — Deno version: deno 1.38.0

In the initial test results using Node.js v20.9 and Deno v1.38, Deno-express didn’t show significant performance improvements compared to Node-express. However, Deno-oak performed notably better. This raises questions about Deno’s compatibility with npm libraries and its ability to deliver faster performance.

But let’s not stop there. You’ll see something more interesting in the second set of results. We tested again using the latest versions LTS of Node.js v20.12.0 and Deno v1.42.1.

The test on MacOs Intel: Node version: 20.12.0 — Deno version: deno 1.42.1

Now, it shows a change in performance. Deno-express and Deno-oak performed better than Node-express, showing that Deno works better with more npm libraries. This indicates that Deno’s team has made significant strides in improving compatibility and performance.

It’s important to note that these tests involved simple scenarios and may not accurately reflect performance in more complex, real-world applications with larger codebases and intricate ecosystems. As Deno continues to evolve and mature, it’s crucial to monitor its performance and compatibility with npm libraries.

How about the Deno community?

Although Deno is still being actively developed and has a growing community, Node.js has a larger and more established community. On GitHub, Node.js has more stars, indicating greater popularity and activity. But, Deno is newer than Node.js, so it’s normal for its community to be smaller for now.

More developers are creating packages for Node.js than for Deno. This might not be a problem for Deno in the long run. If Deno continues improving its compatibility with npm, more developers might start making packages for Deno too, expanding the available tools and libraries for the Deno ecosystem.

Remember, communities can change over time. So it’s a good idea to keep an eye on both Deno and Node.js communities to see how they grow.

Deno in production use cases

Despite its relative youth, Deno has already gained traction in production environments with forward-thinking companies like Deco.cx, Netlify, Supabase, Slack, Github, Supabase, Sportify, Salesforce, Stripe, Bank of America, Indeed, Tencent…

• Deco.cx leverages Deno for dynamic content rendering and API endpoints, citing its built-in security features and efficient performance as key benefits.
• Netlify employs Deno for serverless functions, appreciating its TypeScript support and seamless integration with their platform
• Supabase use Deno for edge functions and backend components, attracted by its ease of use and scalable architecture
• Slack used Deno to save months of engineering effort in launching their new platform

While these are early adopters, the growing list of successful production deployments demonstrates Deno’s increasing viability. The limited ecosystem and community support might pose challenges, but they also highlight exciting opportunities for contribution and growth.

So, ready to use Deno in production?

Above, we’ve concentrated on the Deno runtime, but let’s not forget that Deno provides extensive support beyond just the runtime. It offers a variety of additional tools, forming a complete ecosystem for you:

• Deno deploy: Develop locally in JavaScript or TypeScript, deploy in seconds globally and scale to billions of requests.
• Deno KV: Read your data in milliseconds, worldwide. Enjoy seamless data consistency with ACID transactions. Develop and test locally using Deno CLI, where KV is built right in.
• Deno queues: built on Deno KV, it uses SQLite when running locally and FoundationDB when running on Deno Deploy for maximum availability and throughput.
• Deno subhosting: Deno Subhosting lets you run untrusted JavaScript from multiple customers in a secure, hosted sandbox.
• Deno cron: an easy way to create scheduled jobs
• Fresh framework: Deno also supports frontend development with its Fresh framework. Fresh follows the reliable approach of server-side rendering and progressive enhancement on the client side. It natively supports TypeScript, TSX, and JSX, making development smoother. Fresh provides convenient features like pre-built assets, shared layouts, and streamlined code management.

Deno aims to provide everything you need to start your projects, which could be great. If all the tools function well, it’s fantastic because you save time searching for other tools or cloud services. However, we’re still figuring out how well these tools perform in real projects. Despite this, we’re hopeful about Deno’s future and would appreciate hearing your thoughts on these tools.

To address the question of whether Deno is ready for production use: It’s safe to say that Deno is gaining attention and seeing increased usage in various projects. Some success stories highlight show how effective Deno can be for development, especially for those seeking safer, faster, and more modern development methods. Exploring Deno for smaller projects or integrating it alongside existing Node.js setups can provide valuable insights without causing major disruptions.

However, it’s important to recognize that Deno is still relatively young and may have limitations, especially in complex migrations or when heavily reliant on npm packages. But it’s continuously improving with new tools like JSR and the new features that enhance its capabilities. So, whether you should use Deno or not depends on your project’s specific needs and your tolerance for risk. Just keep in mind that Deno is like a growing plant — it’s getting stronger every day.

The Deno team is working hard to make Deno faster and more compatible with Node.js. Deno 2 is coming will offer even better integration with Node.js and npm. However, we’re not quite there yet — the progress is currently at 28%.

Watch Deno closely — along with the Bun progress, as they are set to have a significant impact on. These new runtimes could change how we develop software, even affecting platforms like Node.js.

Thanks

Special thanks to @florob95 and @bruno.sinteff for their contributions to this research and project and thanks to all the members at @ekino who reviewed this article.

Stay connected

Stay updated with our latest insights and stories from Ekino by following our page here.