The last couple of days, I've come across a lot of my favourite tweeple talking about Deno.
Having just recently re-entered the JavaScript universe after almost a year of Java, I was like wait a second.
A few google searches later, I came to realize that that the JavaScript universe had given birth to it's newest creation - Deno.
So why is everyone on the internet suddenly talking about this cute little dinosaur in the rain?
Earlier this week, the team at Deno, dropped its first stable release, Deno v1.0. It's got a lot of cool features, and people are really excited to see if this will "kill" Node.
But there's nothing wrong with Node?
Well, that's partly what I thought too, until I saw Ryan Dahl's(he created Node) talk at JSConf EU from 2018 and came across a couple other articles such as this.
In his talk, Ryan speaks about 10 things that he regrets building into Node. I've elaborated more on what I consider the most important from those ten, but definitely check out the video below.
Security
While V8 is a secure sandbox, in some situations, there's no reason for certain applications to have access to the file system or the network. Access to these entities should be restricted and access-controlled. Ryan's example of a linter not needing access to the underlying system perfectly encapsulates this.
Promises
Promises were initially added in June 2009, but later removed in February 2010 from Node - in an effort to remain minimal and do away with the overhead they introduced of an extra object into every callback. While this move allowed the eco-system to develop Promises as we know them today, Dahl attributes the problem with the "current aging async APIs" to not sticking with promises initially.
Package.json
This file has become the heart of pretty much every node project. The original idea apparently wasn't really to have a directory of files that package.json has become. This is made worse by the fact that npm has become a private centralized source of these packages. Coupled along with the "unnecessary" information about the package name, license,etc - things could be better.
Node Modules
Dahl believes having node_modules massively complicates the module resolution algorithm. There were simpler ways to do this. I like this particular article that elaborates a bit on the topic of module resolution
As a disclaimer, this talk is from 2018, and I'm sure things have changed ever since. I do understand that fundamental issues regarding native TypeScript support and security remain.
While these issues exist, due to the large number of users that Node has, it is massively difficult to bring about sweeping changes in the current system.
Thus, Deno.
So, what is Deno?
Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.
And how is it different from Node again?
Security
To begin with, the code is executed in a secure sandbox, just like it would be on a browser. Your code cannot access the hard drive, open network connections without your permission. It always requires explicit permission for file, network and environment access. It has built in flags for this such as --allow-net.
First Class TypeScript Support
One of the most painful issues I've come across while working with JavaScript is the lack of type-checking built in. TypeScript supports that, and so does Deno. All of Deno's standard modules are written in TypeScript.
Promises
In Deno, the lowest level binding layer to the system, called "ops" are tied to promises. All callbacks in Deno thus, arise from promises.
Rust APIs
Deno internally is a collection of Rust modules that are integrated at different layers.
Package Management
Deno doesn't use NPM. Yeah. Wow. It directly references URLs or file paths. Oh, it also does not use package.json in its module resolution algorithm.
Caching
Code that is remote is cached on the first execution, and not updated till you explicitly ask for it to be reloaded.
TDLR?
Deno definitely seems promising. It's simplicity is definitely a step up from Node, but only its adoption over a longer time will really tell.
The one tweet that really stood out to me, is this one:
Bradley Farias@bradleymeck
Most exciting thing about Deno? Node getting a competitor. Competition is a way to bring progress by showing innovation and allowing evolution beyond the initial shock.23:01 PM - 13 May 2020
24
308
I'm really excited to see how Node steps up to the competition now.
Are you planning on trying out Deno? Let me know in the comments what you're building with it!
Top comments (0)