Deno is the same as Node.js, but different

JavaScript has been on a roll for more than a decade now. What started as a language used for sprinkling some interactivity to static HTML has grown to be arguably the world's most widespread general purpose programming language. The hegemony of JavaScript is also evident on the server side, with Node.js being a staple of job ads for many years. Recently there's been some buzz around a similar technology: Deno

Let's find out what Deno is and how it compares with Node.js. First things first: The name Deno is an anagram of Node, and they are two different open source software projects. Deno sounds like a cheap knock-off of the more established Node.js, given the two technologies' problem domain and overall similarity. But once you learn both were originally kicked off by the same person, Ryan Dahl, it changes the perception.

Dahl released the first version of Node.js in May 2009. In January 2012 he stepped aside from the project to focus on other things. To the surprise of many he announced Deno in 2018 at a conference talk titled 10 Things I Regret About Node.js. in his talk, the primus motor of Node.js outlines some of the things he'd do differently today. That is what Deno is: An alternative take on a server-side JavaScript runtime.

Since the unveiling of Deno a developer community has grown around it. To many outside of the dev realm their efforts culminated in the launch of 1.0 in May 2020.

What do Node.js and Deno have in common?

Both Deno and Node run on the same technology platform: The V8 JavaScript engine. This is a widespread JavaScript runtime that is largely developed by Google for their Chrome web browser, but is also present in Chromium variants like Opera and Microsoft Edge. The V8 project has received huge investments in time and resources from volunteers and companies. In short, V8 is a killer: It's blazing fast and gets new language features from ECMAScript-262 (the standard that defines JavaScript).

Node and Deno both do more or less the same thing: They run JavaScript code on a server (yes, there is always a server, even if you're serverless). The range of apps that can be built is wide; a data pump proxying streams of data from one location and format to another is a common use case, as are API backends for SPAs, but you can also write complex full-stack backend apps like the Ghost blogging platform or custom apps with a framework like Next.js that runs on the server and the client.

The shared architecture of JavaScript/V8 means both share similar performance characteristics. There can be some differences, where one is better than the other - but as a baseline both are performant enough for most uses and can be scaled horizontally. If you're looking for the absolute best throughput you should probably look at something like .NET Core or something very low level. There are areas where V8 performance won't cut it, but if you're in those fields then you probably know it.

The JavaScript ecosystem is massive. The core skills you need to work with either Node or Deno are very similar. The syntax is identical, even though Deno actually enforces the use of TypeScript in the userland. TypeScript is a superset of JavaScript, adding optional typing and other features that can be useful in development phase. It's also worth noting that you can also develop Node.js apps in TypeScript, and ultimately the V8 engine executes loosely JavaScript that is compiled from the TypeScript source.

How is Deno different from Node.js?

Unlike with Node, the use of TypeScript is a requirement with Deno. Some parts of Deno itself are written in TypeScript, but the team is looking to change that as it is not well suited for that purpose. TS is not strictly typed and does not offer a bullet proof runtime enforcing 100% type safety, but relies quite a bit on type inference to enable type checking and associated development time tooling in IDEs for JavaScript.

Another significant difference is the security model. Node.js never had a universal security model baked in. This means that it easy to write code that will do a lot of harm in the wrong hands, maliciously or accidentally. The approach in Deno is different, in line with browsers and the Ibexa DXP permissions model:

Deno is secure by default. Therefore, unless you specifically enable it, a deno module has no file, network, or environment access for example. Access to security-sensitive areas or functions requires the use of permissions to be granted to a deno process on the command line.
- Deno Manual: Permissions

The standard library is another area where Deno is different from Node.js. Node has a fairly small standard library, which has lead into a large number of external packages for (what some think) should be offered by default in the distribution. For Deno this is again different, as they offer a more comprehensive standard library inspired by Go:

deno_std is a loose port of Go's standard library. When in doubt, simply port Go's source code, documentation, and tests. There are many times when the nature of JavaScript, TypeScript, or Deno itself justifies diverging from Go, but if possible we want to leverage the energy that went into building Go. We generally welcome direct ports of Go's code.
- Deno Standard Library

Related to external packages, this is another big difference between the two. Node.js relies on a central repository, NPM, for storing and delivering libraries and other code. This ecosystem is a huge benefit for developers as it reduces duplication. With over a million packages on NPM, it's a common phrase to say there's an NPM package for that in the developer circles. And often this is true, and the benefits are obvious.

Shared code is good code, and Deno does not intend to implement everything in the stdlib. What is fundamentally different is the distribution model. Instead of a central repository, any URL can contain a package. The project hosts a set of packages over at deno.land/x, but it is not enforced anywhere. This means there is no central owner like with NPM (now owned by GitHub owned by Microsoft). This approach means you can host a HTTP server (public or private) and reference libraries directly from there.

Another area related to extensions is the simplification of code packaging. When Node.js came around, there was no standard module format in the ECMAScript spec. This is why Node.js rolled its own module format, known as CommonJS. Because of the popularity of Node.js, CommonJS became the de facto standard for modules in the JavaScript ecosystem. Since that time the ECMAScript has received regular updates and now includes a standard JavaScript Modules that also work in browsers.

Nowadays Node.js also supports JavaScript modules, but much of the ecosystem continues to use CommonJS. Both formats do more or less the same thing, but with a different syntax. This can make it confusing to work with Node since you can use two different ways for a core functionality. Deno standardizes on ECMAScript modules.

Finally there's the mascot, Deno. Just take a look at the artwork from the collection (blog post main image courtesy of Dimitrij Agal). Who could say no to the lil' one?

Conclusion

As we've learnt there are a number of similarities between Deno and Node.js, but also some key differences in philosophy and implementation. Perhaps the most controversial difference is the novel take on dependency management in Deno. Resolving a complex set of dependencies could be more challenging (and potentially more unreliable) in this fully distributed model. It's worth noting that you can use packages from the NPM catalogue with jspm that hosts NPM packages as ES modules.

Node.js has massive clout on the market, it is a hot technology and developers are sought after by both startups and enterprises. The vibrant ecosystem proves that there is nothing fundamentally wrong with Node.js and it is a big part of the JavaScript success story of the last decade. Node.js is not going anywhere, but Deno could carve out a niche for itself. One thing that comes to mind is FaaS (Function as a Service), whose development could be simpler with Deno's more extensive standard library.

But wait a minute... This is the Ibexa blog. What's Deno got to do with you? Well, nothing as of now. We're using plenty of JavaScript, for example, React.js components for the administration user interface, and our asset build pipeline is Node.js based, courtesy of Symfony Encore. But as of now the Ibexa DXP line of products aren't utilizing any active JavaScript server daemons in Node.js, Deno or Netscape Livewire.

Implementations where Ibexa DXP is deployed are a different case. Our technology is often a piece of a puzzle involving many technology components, from A/B testing services to integrations to enterprise backend systems like ERPs. This is where server side JavaScript is widely used, most commonly as Node.js apps that also run on Ibexa Cloud, but increasingly as cloud functions like Azure Functions or AWS Lambda.

As a melting pot of data and services a Digital Experience Platform needs to be able to interface with everything. This is why it is good for our clients, partners and us to be aware of emerging technologies. Integrations are key for DXPs and Deno could be a contender in that space in the near future. And even if it is not, you always learn by studying alternative solutions to problems. Even the ones you choose not to go for.