In 2009 Node debuted. As runtime environment that supported server-side Javascript, it was a bit of an odd specimen but it quickly generated buzz and widespread adoption. Node took JS out of the browser and used it to power a runtime process. There are several advantages to this approach, specifically from the view of web development. One of the clearest benefits is to give web apps uniformity across the implementation. Having the same language run on both the browser and server eliminates assumptions and improves module cohesion. A programming language may or may not work well with another but it always works well with itself. It also makes sense to model web server on single-threaded event-driven concept that runs on browser engines. Node uses the same V8 engine that runs in Chrome. Using the same language on the frontend and backend also clips the learning cost for developing full-stack web apps making Node a good choice for someone who wants to get set up and going fast.
There are however some shortcomings to Node. Javascript was not intended to be a server-side language and had to be taken out of its natural habitat in the browser and modified to fit that role. As a dynamically typed language with in-built garbage-collection and memory management routines, JS forces certain rules on the server that might better be controlled. Specifically, as a dynamically typed language JS introduces some noise into server design. If a number unexpectedly gets cast into a string somewhere in a complex backend process that is almost sure to break something at some point. Generally you want to explicitly declare variable types and control memory allocation on the backend, features that JS is highly opinionated about or automates away.
Another issue with Node is that JS is a rapidly evolving language and was a different animal over a decade ago. In particular, latency issues involving the EventEmitter API made JS unsuited to processing asynchronous I/O operations. Node quickly inherited technical debt and had to be jerry-rigged to accommodate implementational advances in the language. JS has no built-in method for dealing with asynchronous I/O, without which you effectively can’t do what servers are supposed to do. So Node, which is written mainly in C, had to accommodate for that.
Deno, spearheaded by the creator of Node, Ryan Dahl, is a response to these problems. It isn’t a fork of the Node source code but an entirely new project that attempts to reimplement some of the needs addressed by Node while casting it in a new and improved mould. Here we’ll go into some detail on what Deno is about and how it could be a fresh and invigorating take on server-side JS.
One big difference with Deno is first-class typescript support. For the uninitiated typescript is an extension of JS that allows for optional strict typing for values. The result is a more predictable, tightly controlled context. Adding the typing facilities of TS allows you to start with quick hacky implementations and then scale up to more rigorously foolproof code without having to fundamentally alter the code structure.
Node was developed before the ES6 introduced the now indispensable Promise object. Deno is designed with promises in mind, streamlining callback handling. Deno is built around the ES modules rather than CommonJS specification. It also supports the handy async/await syntax which has made life much easier for developers using JS. In general, Deno is designed to be more consilient with the browser and web APIs. For example Javascript’s inbuilt fetch API, which is used to handle HTTP resource transactions, is part of Deno’s repetoire.
Unlike Node which allows for open access by default, Deno has a secure permissions policy. Any access to the OS layer, file system, or environment must be enabled. Your linter should not have access to your whole computer unless you want it to for some reason. Deno is sandboxed by default.
Deno works out of the box as a single executable. Deno also comes with built in code formatter, unit testing, and CLI tools. Deno does not use NPM to install dependencies. Instead it is built on the ubiquitous URL protocol and PATH technologies to reference modules. The result is a leaner, more compact runtime!
Reliance on URLS for module imports has the advantage of perfect specificity. A URL by definition is a unique reference to a resource location. In contrast, linking to a package associated to a filename could run afoul of namespace resolution algorithms. node_modules, the massive root file for Node’s resources, contains a reference to a module and so does package.json. This is needlessly confusing. By the way, package.json is going the way of the Deno and will not be used with it. The concept that modules should be managed as a directory of files is not native to the web, where URLs prevail. package.json demands that module versions be tracked in a dependencies: list. If libraries were instead linked by URLs the path to the url defines the version. It’s a simplified approach to dependency linking. Deno also caches the dependency the first time it builds, so you will not have to worry about a url instabilities or a url pointing to an outdated resource unless you want to update it with the —-reload command. Because of this you can also run the app offline.
In Node, node_modules is installed locally in every project greatly increasing the size. The inefficient module resolution algorithm that traverses the node_modules file tree can be dispensed with if a more direct url pathing method is used.
There's more to Deno, but this gives you an overview of some of its motivating ideas and how it differs from its predecessor. So will Deno replace Node? Time will tell. The first production-ready version of Deno was released in early May 2020 and at this writing it very much in its infancy. Node has robust support and widespread representation in countless production builds of established companies. Deno may indeed spell a categorical improvement over Node, but that does not mean it will become industry standard quite yet. Nor does it certainly mean that Node is on the way out. That said, Deno embodies years of thinking about how to improve Node using concepts from a much evolved Javascript language and carefully considered design decisions. It will be interesting to see what becomes of this new technology in the near future.
Top comments (0)