PostHole
Compose
Login
SE Radio 553: Luca Casonato on Deno
Luca Casonato joins SE Radio's Jeremy Jung for a conversation about Deno and Deno Deploy. They start with a look at JavaScript runtimes and their relation to Google's open source JavaScript and WebAssembly engine V8, and why Deno was created. They discuss the WinterCG W3C group for server-side JavaScript, why it's difficult to ship new features in Node, and the benefits of web standards. From there they consider the benefits of creating an all-inclusive toolset like Rust and Go rather than relying on separate solutions, Deno's node compatibility layer, use cases for WebAssembly, benefits and implementation of Deno Deploy, reasons to deploy on the edge, and what's coming next.
Luca Casonato joins SE Radio’s Jeremy Jung for a conversation about Deno and Deno Deploy. They start with a look at JavaScript runtimes and their relation to Google’s open source JavaScript and WebAssembly engine V8, and why Deno was created. They discuss the WinterCG W3C group for server-side JavaScript, why it’s difficult to ship new features in Node, and the benefits of web standards. From there they consider the benefits of creating an all-inclusive toolset like Rust and Go rather than relying on separate solutions, Deno’s node compatibility layer, use cases for WebAssembly, benefits and implementation of Deno Deploy, reasons to deploy on the edge, and what’s coming next.
Show Notes
Related Episodes
- 230 – Shubhra Kar on NodeJS
- 372 – Aaron Patterson on the Ruby Runtime
- 413 – Spencer Kimball on CockroachDB
Resource Links
- Cloudflare Workers (Competing product to Deno Deploy)
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Jeremy Jung 00:00:16 Today I’m talking to Luca Casonato. He’s a member of the Deno Core team and a TC39 delegate. Luca, welcome to Software Engineering Radio.
Luca Casonato 00:00:25 Hey, thanks for having me.
Jeremy Jung 00:00:27 So today we’re going to talk about Deno, and on the website it says Deno is a runtime for JavaScript and TypeScript. So, I thought we could start with defining what a runtime is.
Luca Casonato 00:00:39 Yeah. That’s a great question. I think this question actually comes up a lot. Sometimes we also define Deno as a headless browser, or I don’t know, a JavaScript execution tool. What actually defines a runtime? I think what makes a runtime a runtime is that it is a) it’s implemented in native code: It cannot be self-hosted — like, you cannot self-host a JavaScript runtime. And it executes JavaScript or TypeScript or some other scripting language without relying on — well, yeah, I guess it’s the self-hosting thing. Like, it’s essentially a JavaScript execution engine, which is not self-hosted. So yeah, it maybe has IO bindings, but it doesn’t necessarily need to. Maybe it allows you to read from the file system or make network calls, but it doesn’t necessarily have to. It’s, I think the, the primary definition is something which can execute JavaScript without already being written in JavaScript.
Jeremy Jung 00:01:30 And when we hear about JavaScript runtimes, whether it’s Deno or Node or BUN or anything else, we also hear about it in the context of V8. Could you explain the relationship between V8 and a JavaScript runtime?
Luca Casonato 00:01:47 Yeah, so V8 and JavaScript core and SpiderMonkey, these are all JavaScript engines. So, these are the low-level virtual machines that can execute or that can parse your JavaScript code, turn it into byte code, maybe turn it into compiled machine code, and then execute that code. But these engines do not implement any IO functions. They implement the JavaScript spec as is written, and then they provide extension hooks for, they call these host environments — like, environments that embed these engines to provide custom functionalities to essentially poke out of the sandbox out of the virtual machine. And this is used in browsers, like browsers have these engines built in; this is where they originated from. And then they poke holes into this sandbox virtual machine to do things like, I don’t know, writing to the DOM, or console logging, or making Fetch calls and all these kinds of things.
Luca Casonato 00:02:39 And what a runtime essentially does, a JavaScript runtime is it takes one of these engines and it then provides its own set of host APIs, like essentially its own set of ‘holes’ it pokes into the sandbox. And depending on what the runtime is trying to do, the wya it will do this is going to be different, and the sort of API that is ultimately exposed to the end user is going to be different. For example, if you compare Deno and Node, like Node is very loosey-goosey about how it pokes holes into the sandbox; it sort of just pokes them everywhere, and this makes it difficult to enforce things like runtime permissions, for example. Whereas Deno is more strict about how it pokes holes in the sandbox. Like, everything is either a web API or it’s bind in this Deno namespace, which means that it’s really easy to find places where you’re poking out of the sandbox.
Luca Casonato 00:03:24 And really you can also compare these to browsers. Like browsers are also JavaScript runtimes. They’re just not headless JavaScript runtimes, but JavaScript runtimes that also have a UI. And yeah, there’s a whole bunch of different kinds of JavaScript runtimes. And I think we’re also seeing a lot more like embedded JavaScript runtimes. Like for example, if you’ve used React Native before, you may be using Hermes as a JavaScript engine in your Android app, which is like a custom JavaScript engine written just for React native. And this also is embedded within a like React native runtime, which is specific to React native. So, it’s also possible to have runtimes, for example, that can be where the backing engine can be exchanged, which is kind of cool.
Jeremy Jung 00:04:05 So it sounds like V8’S role — one way to look at it is it can execute JavaScript code but only pure functions. I suppose.
Luca Casonato 00:04:13 Pretty much, yeah.
Jeremy Jung 00:04:15 You can do anything that doesn’t interact with IO. So you think about browsers, you were mentioning, you need to interact with the DOM or if you’re writing a server side application, you probably need to receive or make HTTP requests, that sort of thing. All of that is not handled by V8. That has to be handled by an external runtime.
Luca Casonato 00:04:39 Exactly. There’s like some exceptions to this. For example, JavaScript technically has some IO built in within its standard library — like math.random, its random number generation is technically an IO operation. So technically V8 has some IO built in, right? And like, getting the current date from the user, that’s also technically IO. So, there’s some very limited edge cases. It’s not that it’s purely pure, but V8 for example has a flag to turn it completely deterministic, which means that it really is completely pure. And this is not something which runtimes usually have. This is something, like the feature of an engine because the engine is like so low level that it can essentially, there’s so little IO that it’s very easy to make deterministic where a runtime higher level has io, much more difficult to make deterministic.
[...]