Deno vs. Node.js vs Bun: Full Comparison Guide

Until about 5 years ago, almost all of America's nuclear arsenal was run on giant IBM 1 floppy disks.

Some claim it was because it couldn’t be hacked, but a prevailing theory is that it was just a hassle to move everything across to a new system.

Even funnier, it seems like one of the main reasons that the system finally got updated, is that all the original technicians aged out, and the new guys didn’t know how to use the older technology properly!

The thing is, stuff like this happens all the time. VHS beats out Betamax, and DVD beats out Laser discs.

Each time there was a better tech option but with slower adoption, and that’s kind of what we’re seeing here.

For example

Both Node.js and Deno are JavaScript runtime environments. One was launched in 2009, the other in 2018, almost a decade later.

The thing is, they were both made by the same person - mainly to fix the flaws in the original, and take advantage of new technologies.

Surely this means that Deno is the best option then and used by the most people?

Hmm no…

Just like the government sticking with their floppy disk system, so far developers and companies have been sticking with Node.js.

In fact, over 42.65% of devs in StackOverflow’s annual survey still use Node, while only 2.36% use Deno!

So why is this?

• Is Node better than Deno?
• Are people just hesitant to move?
• Or are the updates just not enough to justify the move?

Our view is that there’s actually a place for both in the ecosystem which is why we teach both Node.js and Deno here at ZTM.

However, in this guide, we’re going to look at both runtimes, their defining features, and why people still prefer to use Node.js for now (even if Deno might technically be the better option).

This way, if you’re about to start a new project from scratch and are not sure which to use, or are thinking about what runtime to learn next to best fit your JS skills, you can make the right decision for yourself.

Oh and just for fun? We’re also going to take a look at the latest runtime on the block that's getting all the hype, Bun, and see how that compares to Node.js and Deno as well.

So let’s dive in!

Deno, Node, and Bun: A mile-high overview

Alright, so a quick recap and overview of each, so we can then understand the differences and benefits of each option.

What is Node?

Node.js is lightweight and ideal for data-intensive, scalable, and real-time web apps that run on distributed platforms - in part due to its event-driven architecture and async I/O functions.

Created in 2009 by Ryan Dahl, Node.js is an open-source, cross-platform JavaScript runtime environment.

Built on the V8 JavaScript engine, Node executes JavaScript code outside a web browser and allows devs to write command line tools and run event-driven server-side scripts.

It handles requests by executing a single-threaded loop registered in the system, and each request triggers a JS callback function. Moreover, it also distributes the CPU load by spawning threads for continuing the CPU-intensive or out-blocking tasks.

This callback scaling mechanism can handle more requests with less memory usage than other competitive frameworks, making it a more efficient option.

Pros + Cons of Node.js

Pros of Node.js

• The Node Package Manager! (NPM)
• It is a fast and scalable runtime
• With cross-platform compatibility, you can run Node.js anywhere on macOS, Linux, and Windows
• It provides the latest security protocols for securing your business apps
• Node.js has a large ecosystem, with a collection of a varied range of libraries, frameworks, and tools that make it easier to develop web apps and APIs
• This has then led to an amazing community and user support. As Node.js has remained popular since it was published, the user community of this environment has grown immensely

Cons of Node.js

• Node isn’t ideal for computation-heavy tasks like video encoding or machine learning
• Some modules are not great in terms of documentation, stability, or support, so evaluate them before using them in your project (In fairness this is true of importing any 3rd party code)

Who uses Node?

So many sites are built with Node!

• Netflix
• Uber
• LinkedIn
• PayPal
• Trello
• Mozilla
• GitHub
• And many more

Want to learn Node?

Here's a sneak peek of the first 6 hours of our learn Node.js course!

Anyways, back to the comparisons.

What is Deno?

Fun fact: Deno is an anagram of Node!

Co-created in 2018 by Ryan Dahl (again), Bert Belder, and a few others, Deno is also a runtime for JavaScript, as well as TypeScript, and WebAssembly.

Built on the V8 JavaScript engine, and with the Rust programming language, Deno was designed to bypass the flaws of Node and was seen as its improved version.

How so?

Well, it was designed with a finer package management system along with a more secure runtime environment than Node.js - thanks to its adherence to web standards.

It also ships with one executable file and offers in-built development tooling, with an alternate set of particular modules that are guaranteed inside the Deno runtime.

Finally, it also runs TypeScript files natively before any more configs.

Pros + Cons of Deno

Pros of Deno

• Deno is secure by default. Deno programs don't have access to the filesystem, the network, etc. — you need to explicitly opt into those via permission flags. Deno's permission flags extend to its dependencies
• Deno natively understands TypeScript code with no third-party compiler required to set up
• The latest module system of Deno will leverage ES modules and allow developers to import them directly from the URL or local path of the files
• Deno is run by an actual company, so they are in it for the long term, with new updates every month (some people may argue this a con but we see it as a pro for now)
• Decentralized module hosting
• DNT. This is a build tool that transforms Deno modules into Node.js/npm-compatible packages. Not only that, the transformed package supports both CommonJS and ESM, can work in Node.js, Deno, and browsers, runs tests in both CommonJS and ESM, and it supports TypeScript and JavaScript!
• Deno compile now supports npm packages

Cons of Deno

• Because it’s relatively ‘new’ at around 6 years old, there isn’t as much community support in comparison to Node, and so it has a much smaller ecosystem. However, they do have ‘Deno by example’, which is a collection of annotated examples of how to use Deno and the various features it provides. It acts as a reference for how to do various things in Deno, but can also be used as a guide to learn about many of the features Deno provides
• Limited utilization of multi-core functions
• Deno can be deployed widely (just not as widely as Node)

Who uses Deno?

A lot of sites use Deno. It’s nowhere near as many as with Node (for now), but here’s a few you would know:

• Netlify
• Slack
• SupaBase

As you can see, Deno has far fewer flaws and the ability to run TypeScript natively, so why are people still using Node so much?

We’ll cover that in a second, but first let’s take a look at the latest kid on the block, Bun, and how that performs.

What is Bun?

Created by Jarred Sumner and using JavaScriptCore instead of V8 like Node and Deno, Bun is an all-in-one JavaScript runtime & toolkit.

It’s designed for speed and comes complete with a bundler, test runner, and Node.js-compatible package manager.

This means that it allows you to develop, test, run, and bundle both JavaScript and TypeScript projects in one location, and early indications are that it’s incredibly fast, but with a few drawbacks.

So what are these drawbacks?

The reason that Bun is so fast is that the team behind it keeps going back to the first principles of ‘what is the fastest way for us to do X’, and then builds that into Bun so that it’s further optimized.

This is both good and bad to some extent, so let me explain.

Often in programming and engineering, something doesn’t quite work how we want it to, and so we create workaround systems.

Then, new processes and systems come out that also rely on those old workarounds.

It’s fine and everything works, but in theory, it could all work faster and more efficiently if we weren’t limited by that very first band-aid solution right?

That’s Buns theory also.

The reason it's so fast is because it solves those band-aid problems that everything else has had to work around. They went back to the original issues and fixed them, meaning it can perform at much higher speeds, shaving off milliseconds here and there, that all add up.

However, it does mean that everything else that originally used the workaround, may have new issues, and so problems can cascade from there.

It’s not a major issue. It just means improving your code to remove the workarounds, and getting a better result - but also more work to implement if you’re already up and running.

Like I say - it’s not a bad thing in theory as everything from there forward should perform better. However, it is extra work and code changes.

Pros + Cons of Bun

Pros of Bun

• It’s fast both in terms of start-up time and execution time
• It uses less memory than Node, meaning you can run applications more cost-effectively on phones, smart watches, etc
• Built-in support for TypeScript and JSX
• Faster package installation (that you can definitely notice)

Cons of Bun

• It’s still in development and is more immature than Node and Deno, meaning businesses are less likely to adopt it for production applications
• The Deno ecosystem is still fairly small after 6 years. Version 1 of Bun is just over 100 days old, so as you can imagine, it is still very early days here
• It doesn’t yet support all Node.js APIs and packages, meaning you can’t drop in all Node programs and expect them to work automatically. (They are pretty good at getting these things fixed and implemented though. They ship almost weekly)
• Most resources are tailored to Node and Deno
• TypeScript is not technically native. You still compile it down to JavaScript and then use other tools such as Webkit to run it

Who uses Bun?

• No one just yet. It’s mainly people building and testing smaller projects. Again though, Version 1.0 has only been out for just over 100 days at the time of writing

As you can see, Bun is fairly exciting and could be a potentially game-changing runtime after a few more versions.

It’s advertised as a drop-in replacement for Node, but in these early stages, it’s not quite there yet but could be down the line. For now, it’s still a little buggy, but worth having a play around with on a personal project, and try it for yourself.

So now we understand the benefits and flaws of each of these runtimes, it’s clear that Deno and Bun have some pretty compelling advantages. The question remains, why are people still using Node?

Well, I think there are possibly 5 reasons…

The 5 main reasons why people still use Node.js vs other options

1. Migration efforts

Unless something is an absolute no-brainer to move across to, people will always have reasons to stay with the tech they currently use.

The pain of staying has to be far bigger than the pain of moving, and that’s true for so many areas of life and business.

For example

We recently looked the best programming languages to learn in 2024, based on job demand, salary, dev opinion, ease to learn, and future-proof outlook.

One thing that took us by surprise, is that PHP (yes, that one) is still going strong even after years of people calling it dead.

Not only was it ranked in the Tiobe top 20 used languages, but it had an average salary of over $109,000 a year, with thousands of current jobs available in the US alone.

Companies would rather pay more for devs who can use older tech, than migrate sometimes...

2. TypeScript support isn't always needed

TypeScript is pretty awesome, in that it lets the user add optional static typing.

Now, we already know that Deno supports TypeScript natively and doesn’t need compiling (and Bun lets you compile down), but the thing is, it’s not that hard to use TypeScript with Node either.

Thanks to the Node Package Manager, you can easily add in TypeScript compatibility, like so:

run npm install -g typescript

Then you can simply run tsc - - init to create a TypeScript configuration file, while the tsc- TypeScript Compiler can be used for compiling your .ts files.

Simple!

TL;DR:

If you want to work with TypeScript, Deno definitely works faster out of the box. But given how easy it is to simply install a module in Node to achieve the same thing means that this isn't a big enough differentiator for someone to use Deno over Node.

Speaking of installing modules…

3. The NPM is awesome!

The Node Package Manager is the default package manager in the Node.js framework.

It allows you to download external packages in the form of modules, and these modules exist in either local or global command-line apps, and it’s one of the major reasons why developers love Node so much.

Add in the fact that the NPM also assists you in adding your own package to the registry for other persons to use in their projects by using a package .json (Derulo) file.

(Jokes! It’s just a standard .json file. It’s just hard to even type .json and not sing his surname… back to the article).

NPM is really easy to use also.

For example

Here’s how much effort it takes to install a package:

# installing a specific package in the current directory
npm install <package>

Or alternatively

# installing a particular package globally
npm install -g <package>

Done!

And yes, Bun does have its own package manager and installs it crazy fast, but not every package works with it yet.

Whereas Deno doesn’t have a package manager. Instead, it helps you to import modules using an SDN, or any private or public GitHub repositories.

Importing packages in Deno can be done like this:

//Import a local file
import { squareRoot } from './squareRoot.ts';
// import from a CDN
import { squareRoot } from "https://deno.land/x/squareRoot/squareRoot.ts";

This open system means that you can get packages from anywhere, but be careful. You want to be secure and only load packages from trusted sources.

Speaking of security…

4. Flexibility beats security (sometimes)

Deno was designed to be secure by default, which means that it requires explicit permission flags for accessing system resources — such as the network, file system, and environment variables — making it less vulnerable to attacks.

For example

• --allow-hrtime for formatting alternatives for printing timestamps
• --allow-env to use variables from your terminal environment
• --allow-read helps Deno scripts to read files
• --allow-net to access network, which by default isn’t accessible in Deno
• --allow-write to help the Deno script write files to the system
• --allow-run to let the scripts execute imported code

Node.js does have the advantages of standard security measures for preventing the attacks of CSRF (cross-site request forgery) and XSS (cross-site scripting), but it is still a less restrictive security model, and that’s part of the irony.

You see, while this model does have more potential for security breaches if you don’t implement all the necessary precautions, it still provides increased flexibility and ease of development.

Most devs seem to be happy with this drawback in exchange for the flexibility in use. It’s just a better developer experience, and so it often wins out.

5. Formatting

Deno has an in-built formatter that minimizes the need for an external tool for installation and configuration. Using the deno fmt command, you can get work that is similar to ESLint and allows auto-format.js, .md, and .ts files.

This can be done by passing the filenames in the deno fmt command.

Deno formatting can also be handled in the terminal, like so:

# formatting markdown and any compatible code samples
deno fmt readme.md
# formatting one directory of code
deno fmt dist/
# format stdin
cat squareRoot.ts | deno fmt –

While Node.js doesn’t have a built-in linter or formatter.

Again though, this isn't a major drawback or selling point to get people to swap (at least not for everyone anyway) as you can still use Node and 3rd party formatting options instead.

There's a lot to choose from also:

JSHint, ESLint, Prettier, and StandardJS have been used for a while to offer options for linting and formatting your code. There are also modern options as well such as quick-lint-js and Rome.

They provide a better development experience and are designed to work exceptionally well with minimal or no configuration at all.

So again, not a major issue for Node devs.

The truth is, good enough sometimes beats better

So as you can see, although Deno has a lot of the key features that developers want already built-in, many of those features and benefits can pretty quickly and easily be replicated when using Node instead.

Sure Deno can run TypeScript without a compiler, and is more secure than Node, but it still has a smaller ecosystem so you might struggle to find support or answers to questions and code snippets, and we all love a shortcut!

Companies (just like the government) aren’t just going to switch their existing projects and codebases to the latest new framework for marginal benefits… The costs and hassle of doing so are too big.

This might not always be the case in the future, as companies start new projects, they may decide to choose Deno from the start.

It could even be the case where new devs that come through all learn Deno or Bun and eventually help to create that mass of users, which is the root cause of Deno’s struggle for adoption.

Not enough users means a smaller community and packages., but that lack of community is also what stops people from using it to some extent. It’s a real catch-22 situation.

Will Node always pull ahead?

It’s difficult to predict the future. However, we can look at the past to get a rough idea of what might happen.

For example

Back in 2014, Node split into two camps, the Node team and the io.js team, whose goal was to include new features more quickly into a stagnating Node. By 2015, they merged into one product, and the Node.js Foundation was created. The resulting Node was stronger than it would have been without the added pressure and competition from io.js.

What if we go back to the StackOverflow surveys from the start of this guide (although Deno launched in 2018, they only have Deno usage data for 2022-2023).

If we compare them side by side via survey respondents, it doesn’t look great for Deno - in comparison at least.

Sure, a lot more devs use Node, but it is trending down slightly.

At the same time, there is a small lift in Deno users. Yes, only 1.41% of Devs surveyed used Deno in 2022, but this did rise to 2.36% in 2023. It might be interesting to see if this continues to slowly grow over time - especially considering how much support Deno has for ongoing updates.

Will Deno's features help them win the long game?

Deno’s entire goal is to keep improving the quality of life for devs. At some point, surely that has to pull ahead right?

Possibly. However, whenever Deno finds a flaw in Node and they build a feature to remove that in Deno, Node then uses that information to fix or create a workaround for the flaw themselves.

It’s great for Node devs but must suck for Deno.

What about Bun? Could it sneak in and pull ahead of both Deno and Node?

It’s way too early to say.

There are definitely a lot of exciting things planned. However, it would still need to be such a huge improvement that it makes the pain of issues in Node or Deno something worth migrating for.

Or alternatively, they need a lot of developers to decide to build with it from day 1.

How many projects are actually being built with Deno?

Another point to consider is that not all people who use a tool will answer surveys.

So what if we take a look at new repositories on GitHub using Deno for each year?

It doesn't look great here. While there was a big jump in 2020, it's been pretty flat since then and the overall number, especially when comparing to Node, is still quite small (only ~2,000 - 3,000).

If Deno was making solid progress in unseating Node.js, then we'd expect to at least see an upward trend.

When comparing to Node, Deno is still tiny. Over 100,000 new repos created and there's actually an upward trend happening.

So which is the best runtime to learn? Node, Deno, or Bun?

For now, the data is pretty clear that Node.js is still the best one to learn.

It’s more popular, has more job opportunities, continues to grow, and pays better, even though Deno is ‘technically’ a slightly better option.

My advice?

• If you’re looking for the best chance to get hired as a backend developer and the best pay, stick with Node.js for now
• But, if you’re starting a brand new project, for either yourself or at your company, definitely consider using Deno for its multiple benefits
• And then if you're working on a personal project, then try Bun out to see for yourself if it's good enough to make the switch on your other projects

P.S.

You should never stop learning if you want to future-proof yourself. So why not learn both Node and Deno?

Like I said up top, we believe there’s a place for each of these runtimes, and that’s why we teach both of them:

• You can learn Node.js here, and check out the first few lessons for free
• And you can learn Deno here, and check out the first few lessons for free

The best part?

If you’re a Zero To Mastery Academy member, then you already have access to both as well as every ZTM course, project, and workshop!

Not only that, but ZTM members also get access to our private community on Discord where you get access to all our teachers, alumni mentors, and other students. It's the largest, most supportive, and most active learning community online.