The Changelog The Changelog #443

Exploring Deno Land 🦕

This week we’re joined by Ryan Dahl, Node.js creator, and now the creator of Deno - a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.

We talk with Ryan about the massive success of Node and how it impacted his life, and how he eventually created Deno and what he’s doing differently this time around. We also talk about The Deno Company and what’s in store for Deno Deploy.


Sign in or Join to comment or subscribe

2021-06-12T04:48:03Z ago

I don’t like “one language apologists”, which you guys keep hosting uncritically on The Changeling” for some reason: “all dynamic languages are basically the same as V8 is the fastest VM in the world” (not a direct quote) so you should write all of your stuff on deno.

So here is and reason to the insanity:

  1. V8 is fast. Is it the fastest? It’s hard to compare apples to oranges - Parrot VM (used in Raku) is plenty fast, and the hotspot VM is also so fast that it can run other VMs on top of it at useful speeds (Graal, JRuby, IKVM, etc), but you can also find benchmarks that compare V8 unfavourably to Spidermonkey and Chakra (
  2. JavaScript is a great language, but it can’t (and shouldn’t try) to do everything for everyone - did you ever try to do process scheduling and automation in JavaScript? Bash excels in that, and a complex setup that can really ruin a JavaScript programmer’s day can be just a few lines of bash. The rimraf npm package is a great example: let’s download a few hundreds lines of JavaScript code off the internet to replicate what a very short and efficient Unix command does very well. Did you ever try to write a grammar in JavaScript? It is something Raku (and generally any Perl) does really well and very simply, but is a hassle at best in JavaScript. I can go on.

And no - bash does not start a process for every line of code.

I would very much like to hear, someday, a developer that invested a lot into some language of framework, saying something like: “this is the tool I chose to use, it is great and here are all the ways it is great, but I recognize there are some usecases for which it isn’t the greatest”

2021-06-17T11:34:21Z ago

Ultimately, I really don’t care from where I import my scripts. As Ryan agrees, if you really want to trust a source, you have to audit the code. However, there is one substantial difference between importing from npm and the script tag on the one side, and an URL on the other side: subsource integrity.

Unless npm has been compromised, I can trust that a (potentially audited) version will be the same the next time I install it. The same is true when the script tag is used with the integrity attribute. As far as I know, ESM imports don’t have an instrument for that. And we all know it’s easy to change a hosted script or its Git tag. So I see importing URLs as a step to simplify dependency management, but it’s not adding security to the system.

0:00 / 0:00