So, why use a different runtime having NodeJS around?
NodeJS, Deno, and V8
On the other side, NodeJS and Deno provide V8 all the methods to access and use system resources such as the filesystem (FS), sockets, etc. In fact, V8 was designed this way so it can be extended to be used in different environments.
Deno starts from the same principle as NodeJS: running JS code in the server. Then, it introduces a new set of design decisions that make it a different and solid option.
Let me highlight some of them:
denois a single binary. Nothing more, nothing less
- Include TypeScript support out of the box
- The security model is capability-based. You need to grant access to system resources when running your application
- Focus on developer experience by including a set of tools for linting and formatting
- Uses ECMAScript Modules (import / export) by default
- No package manager is required. Dependencies points to remote or local files
If I had to choose just 1 item from the list, it would be the capability-based security model. And this moves us to the next section.
Why Deno now?
It is not a secret that NodeJS ecosystem was the target of many, many, many, many malware attacks last years. NodeJS has a vast ecosystem with millions of packages. Controlling all of them and their dependencies is an impossible task.
When there is a new security incident with a package, the focus is the same: removing the compromised version. This strategy takes case by case and applies an action to the individual items. However, the root cause is always the same: any downloaded package gets direct access to many resources in your system.
And this is where Deno shines for me. By default, an application will not be able to access resources unless you explicitly enable it. For example, the following application will be able to read only the
/tmp/my-folder/ folder in your system:
deno run \
https://deno.land/[email protected]/examples/cat.ts \
cat.ts library gets compromised and tries to access your etc/passwd file, it will not be able to read it thanks to the granular permissions you granted. Said that all the packages that
cat.ts runs will get the same permissions.
I do not want to go into details here as that will be a different article in the blog 😄
A flourishing land
Deno is still in its early days. However, they created a solid foundation and now have the tools to make a strong ecosystem around it. Their current focus on developer experience, security and frameworks, make a perfect mix for me.
I am eager to see how it evolves, so expect more articles on this topic.
And before finishing the article, here you have a plot twist: Deno and NodeJS were created by the same person 🤯