Is Deno The Future of JavaScript?

Over approximately this past year a "new" JavaScript runtime has been gaining attention. Made by the same person who made NodeJS, Deno is a JavaScript runtime that is in a lot of ways better.

Is Deno The Future of JavaScript?

Over approximately this past year a "new" JavaScript runtime has been gaining attention. Made by the same person who made NodeJS, Deno is a JavaScript runtime that is in a lot of ways better in terms of compatibility, and among other things. There's plenty of articles out there on this topic, but this is going to be my personal take on where it's going.


One thing that has been in Node for quite a while is backwards compatibility functionality, things like require which was originally created by RequireJS, among other small things are an issue as not only does this not make it compatible in the browser (for use in both front and backend development), but it also in some cases is highly against the ECMAScript specifications.

This is one of the areas Deno succeeds in, in my opinion. Deno does not use anything like require, it uses things from the ECMAScript specifications such as import, but not only this, Deno aims to quite strictly follow the specifications and has as far as I have known even deny feature requests as they have gone against the specifications before. While this can be limiting in some cases, this also means it's extremely compatible with some things as it follows the specs, on top of this Deno also aims to be compatible in the browser excluding their builtin APIs.

Small footprint

One thing about Node is the install has many, many files and that's entirely okay and normal! I'm not hating on Node by any means. However due to this it takes up more space than necessary in my opinion, and could probably save some space in some cases, I'm not going to nitpick here as I'm not well versed in C++ development and libraries, nor the NodeJS code base, I just use it.

Now onto Deno, this was something that shocked me personally, given I've used Node for so many years before even hearing about this project. Deno is a single executable, that's all it is. When you install via their command line installer, or just simply downloading the latest release from their GitHub, it's literally a single executable file. This is partly due to the project being made in Rust, which has some other benefits, but we'll be going into that later on in this article.

Package Management

One thing that has always irked me about node is how much space package management uses. Don't get me wrong NPM is a great package manager for what it is, it does what it does well. However, one thing it doesn't do well is saving storage space, there is alternatives such as Yarn, PNPM, and probably others, and they do save space, as they cache packages previously downloaded, even PNPM goes out if it's way to use symlinks to save as much space as possible.

Deno's package management is a bit more interesting on the other hand to me, instead of a per-project module/package folder, such as node's node_modules folder, Deno stores and caches all modules used in folder(s) inside of your DENO_DIR directory. On top of this, there is no meta files in a "stock" deno project, only the source code for your project, as instead of using a package registry or something similar (besides their third party module listings), you simply import modules via a remote url, for example

import {} from "[email protected]/log/mod.ts";


I love TypeScript, ever since I found about it around the first time it released I've used it as the pseudo-type safety is an amazing feature, as well as using import and other ECMA features by default, and sometimes even getting new language features before normal Node does. However, what I do not love is the fact I have to install a package or module to use it, on top of this having to compile my source manually every single time if I want to use it as Node doesn't support running typescript. There are some projects that help alleviate this to an extent such as TSNode, which gives you a TypeScript REPL on node, but you still have to have both it, and typescript installed.

One of my favorite features of Deno is TypeScript is supported out of the box, the TypeScript compiler is built into the runtime, so running TypeScript files with it just simply works. There's no need for me to install a module or package, everything just simply works. On top of this the Deno standard library is also written in TypeScript, meaning everything has proper types, and documentation and that's lovely when you want your code to be working as expected, especially as it's a standard library!


The one thing I find personally lacking in the Deno world is the package ecosystem. There is certainly packages, but due to the project being so early in development (at least compared to Node), there is not many packages in comparison to how many there is for NPM/Node. If we take a look at their 3rd party listing page, there is as of writing this 1049 packages, while as on NPM there is roughly 1,402,796 packages according to this website. That is a very large difference. This is probably the main downside I can see currently for Deno.

Rust vs C++

This section is going to be smaller than most, as I'm not the most well versed in C++ development. However I am somewhat experienced when it comes to Rust. One thing I quite love about Deno is the fact it's made in Rust, as Rust grants quite a few benefits compared to C family languages, such as immutability by default, thread and memory safety, among other things. This being said, all these checks probably do have overhead, in the end the runtime is still pretty fast in my experience, you can checkout their benchmarks for more information and data.

Is it the future?

While I can definitely see Deno rising up and becoming a popular runtime, the sheer amount of libraries and technologies using Node is massive, switching runtimes no matter what runtime it is, is a lot of work, and on top of this Deno's node compatibility layer isn't fully completed just yet making switching away from node even more of a hassle. In the end Deno is still very small, and for now most projects will most likely stick with Node. So I think it won't be for at least a few years before Deno starts getting used more often than it is.