Deno won’t replace Node

I was there as Ryan Dahl announced Deno at JSConf EU 2018 . The audience was buzzing. Back again almost 10 years after, announcing the mistakes he made with Node and how he has fixed them. An anagram om Node is announced: Deno ! TypeScript by default, security by default, no npm, no cuteness for cuteness' sake. We love new shiny things that can replace old shiny things, and this was no exception. Initially I didn’t think too much of it. I don’t particularly like people discrediting other’s work (yes, Ryan Dahl started Node and is very talented, but didn’t make Node what it is today), and I don’t think him thinking they were mistakes necessarily makes them mistakes. So I kind of forgot about Deno. Until Deno 1.0 was released .

I did a podcast episode on it so I had to look deeper into it. Turns out it is very interesting, and it is very good . It has made great progress over the two years of its existence, and many people have come together to create some really neat concepts. It is fast, I like the TypeScript integrations and how the CLI create type definitions you can check-in to your repository. I like the standard library, I like the Deno -global, and that it is written in Rust with the ability to do plugins to the platform itself. I also kind of like the simplicity of URLs as external code without having to use a centralized repository. I really like Deno . But I like for what it is, which is not a replacement for Node.

Why not a replacement for Node?

Node is a platform for writing applications. It started as a way to write scripts and running scripts locally, but over the years it has evolved to a platform for writing applications. We do Node on the Cloud™ and we do Node on hardware units. We do Node everywhere. The architectural principles of Node allow us to scale from a small level, to a large level.

Deno is a redo to make a platform for writing scripts (which it does brilliantly, in my opinion). It solves the problem domain of small sets of instructions to do one particular task (and it solves it really well). This overlaps with Node’s problem domain, but only part of it. This impression is also backed up by Deno’s manual:

Among other things, Deno is a great replacement for utility scripts that may have been historically written with bash or python.

I believe this was the original intention of Ryan Dahl with Node as well. But over the years, with the great work of many people, it has iterated and changed its intention and problem domain. I would argue, for the small scale scripting Deno does a way better job. But it doesn’t at all solve the large scale application problem domain. And this is fine. I love tools for specific problems, just like Deno is .

I will give you one example of a limitation that exemplifies the lack of support for large scale application implementations. It’s not the lack of community tooling like PostCSS/SASS/Less or OpenID/OAuth (*maybe these exist but not in the Deno database). It’s the inherent nature of the choices Deno has made: Modules are not downloaded locally but referred to as URLs and resolved in install-/run-time and cached locally. This is incredibly handy when doing scripting, but a massive limitation when doing larger modules or applications. Why? Because it means you cannot interact with the file system in the same way when the module is published. And as it turns out, file systems are quite handy.

And when running locally, Deno makes copying files, reading files, writing files, interacting with the file system very simple. And everything was a breeze as I was creating a CLI tool for creating a static site from Markdown files. I wanted to copy a folder with static assets from my CLI to the current working directory of the consumer. This worked seemingly as expected. Until I published the module and tested it out as a tool. When publishing a Deno module, you host script files on a static file server. You move from working on a local file system (when developing) to using HTTP (when published). So my copying no longer worked. And thinking about it makes total sense. When resolving modules on a remote location, you can’t use the file system as the protocol has changed. Instead of opening files you now internally do a HTTP Request (fetch).

For my particular problem, there are a couple of ways I could handle this as I see it. I could use a zip file. But this would require more work when running locally and will be less developer-friendly. Or I could check import.meta.url to see if you are on a file system or not.

const isModule = !import.meta.url.startsWith("file://");async function getFileContents(name: string) {
  if (!isModule) {
    const decoder = new TextDecoder("utf-8");
    return decoder.decode(await Deno.readFile(src(name)));
  } else {
    const url = href(name);
    const data = await fetch(url);
    return data.text();
  }
}

But this doesn’t work on directories without keeping an internal register of all the files. Another big drawback of this example is that you end up running different code in development and production. Meaning you are much more likely to have bugs without catching them before deploying your code (as I did).

Deno is optimized to work on a file-to-file basis. When importing the next file, you do only that: importing the next file. That file can import another file, and so on. Deno has moved the module resolving to be distributed through HTTP requests. This is perfect for creating consumer scripts. On the other hand, Node works on a package-to-package basis. It transfers entire directories as tar-files to be placed locally on your file system and then having the module resolving be handled locally. This is a key difference as Deno works on files and Node works on packages.

This is just one example, but for me it represents a larger architectural and philosophical difference. Deno is not intended to work this way. It optimizes for working locally, not for having packages. This is in line with being a scripting platform, not an application platform.

These limitations can change. They are only technical hindrances that can be amended. But I don’t think that it will change as the philosophical goal of Deno is not to be an application platform. As with Node.js in the beginning, it tries to be a clean scripting language more than an application platform. And as such, it won’t replace Node and has no intention to. It can, and in many cases should replace bash (a discussion for another time). Keep in mind, I have limited experience with Deno, and have no direct line the Deno team to know what their philosophical convictions are. I may be wrong. But I don't think I am.

Deno seems great. And Node is great. But for Deno’s sake, we have to stop thinking that it operates in the same problem domain as Node and rather judge it for what it’s merits are. But it certainly won’t replace Node, and I don't think it has any intention of doing so.