Deno? Do you mean Node?
15 May, 2020 - 5 min read
The last couple of days, I've come across a lot of my favourite tweeple talking about Deno.
Is it pronounced Deno or Deno?— Tyler McGinnis (@tylermcginnis) May 14, 2020
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.
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 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.
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.
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.
So, what is Deno?
And how is it different from Node again?
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
First Class TypeScript Support
In Deno, the lowest level binding layer to the system, called "ops" are tied to promises. All callbacks in Deno thus, arise from promises.
Deno internally is a collection of Rust modules that are integrated at different layers.
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.
Code that is remote is cached on the first execution, and not updated till you explicitly ask for it to be reloaded.
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:
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.— Bradley Farias (@bradleymeck) May 13, 2020
I'm really excited to see how Node steps up to the competition now.