Deno is the same as Node.js, but different
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.
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?
How is Deno different from Node.js?
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 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.
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.
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.