Is Deno the next Node?

·

3 min read

Deno finally reached v1.0 in May 2020 and after stumbling across this I'm intrigued. Like Node, it is a runtime for JavaScript that uses V8 and installs easily on Windows and Mac with some neat additional features;

Secure by default. No file, network, or environment access, unless explicitly enabled

When you run your application with Node it gives direct access to your computer, network, environment variables etc. So you can see how this might leave you vulnerable.
Deno avoids this by running your application in its' own sandbox and you have to explicitly give permissions so you know exactly what has access to what. Check it

Supports TypeScript out of the box

If you've been working on Node projects any time over the last 2 years, likelihood is that you've noticed the growing popularity of TypeScript. So this is a perfectly timed feature!

TS-downloads--sept-18-20.png

Ships only a single executable file.

All it needs to run is a 15MB executable ⚡
Brilliant. Not only is it just this little file but it also does the job of both runtime and package manager, has a CLI to run some nifty utility scripts and uses URLs to load modules (as browser standard).

Has built-in utilities

Deno has its' own bundler, which doesn't replace Webpack yet but it outputs a single JavaScript file including all the dependencies and can be run in deno like any other module. Deno implements web standard APIs, has a dependency inspector, documentation generator, formatter, test runner and linter!

Has a set of reviewed (audited) standard modules that are guaranteed to work with Deno

I mean, this is good right? Plus Deno can import any web modules, like GitHub, web servers, or CDNs. It also provides built-in tooling to consume and publicly host third party modules that work with Deno.
I know I just said it does the job of a package manager, but it's key to note that it isn't a package manager, at least in the traditional sense. Because it uses direct package imports, the standard practice for managing dependencies with Deno is to add a deps.ts file and have dependent local modules reference that.

Conclusion

It seems to present a strong alternative to using Node although it's still early days but a couple of key things to bear in mind is that it isn't 100% compatible with Node, which might make it tricky to migrate an existing project over and for that reason it probably won't replace Node for a while. From a frontend perspective, I have some questions about how we can handle code-splitting and SEMVER or if need be - how we can use Deno efficiently without these. But I'm really excited about this, I'm keen to keep playing around with it and I'll be keeping a close eye on future developments!