5 ms·

> Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. Still don’t fully understand what ‘runtime’ mean

> Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. Still don’t fully understand what ‘runtime’ means in this context. It’s not the parser, interpreter, VM, GC I think, because that is the V8 part. It’s not a runtime compiled into an executable like Haskell or Go. Is it the term used here for a set of standard libraries? Or maybe in interaction layer with the operating system underneath, or the package/build system? Or an umbrella term for all of this? I’ve been doing all kinds of JavaScript and TypeScript for a long time now without a runtime (I think) so pretty curious.

wiseowise 3y ago
> I’ve been doing all kinds of JavaScript and TypeScript for a long time now without a runtime (I think) so pretty curious. Node and browser are both runtimes for your JS code.
skybrian 3y ago
V8 is a library that gets embedded in some larger program. It doesn't determine how imports work or any API's, and if you don't have any API's to call, there's not much you can do in JavaScript. A browser does all that, so that's the runtime. Similarly for Node's import resolution and its API's for doing I/O. You could think of it as all the code in the 'deno' or 'node' command other than V8 itself.
- sfvisser 3y ago
  Got it. Maybe I always naively assumed there is some shallow FFI layer and all the heavy lifting is done by some set of core standard libraries. Ideally portable to multiple environments.
  - skybrian 3y ago
    There’s some of that. I/O in node is done by a C library called libuv [1]. It’s portable and it’s used by other languages too. Deno doesn’t use it, though. They use Rust ecosystem libraries like tokio. [2] [1] http://docs.libuv.org/en/v1.x/ http://docs.libuv.org/en/v1.x/ [2] https://choubey.gitbook.io/internals-of-deno/architecture/tokio https://choubey.gitbook.io/internals-of-deno/architecture/to...
goku12 3y ago
The additional thing that node, deno and even a browser supplies (aside from what V8 does) is an API layer and sandboxing features. So perhaps, 'the interaction layer', as you put it?
veidr 3y ago
I know what you mean. I feel like the term "execution environment" better describes it, but "runtime" has historical momentum in the JS world (I think), so changing it might cause other confusion. I think (probably) you've been doing your JS/TS in a "runtime" but that was probably either a.) the browser, or b.) Node.js. In the (pretty weird, IMHO) JS world, this notion of "runtime" amounts largely to what magical global variables are available. And then, what language features are available. Deno (properly, IMLHO) hides most of its "nonstandard" features behind one magic global variable: Deno. The rest of what it offers is "standard" which Deno (and all sane persons IMNSHO) interprets as "what the browser supports". Even that's fucked, in JS-world, because there are a bunch of browsers, and each one of them is like "yea woo I love standards, but fuck that standard". But browsers have a standard, more or less, it's just that all browsers implement only a subset of it. Still, to me, that's "the standard". So Deno implements its own subset of that standard (but they seem to try hard to implement as much as possible), and then it adds its own "Deno" global object for everything else (like local filesystem access, key-value database, etc that browsers don't support). An execution environment like Node hasn't traditionally prioritized compatibility with "the browser" and so instead it offers a bunch of top-level built-in things like "fs" or whatever, that you "require()" and then you can use them. And standard things that exist in al(most al)l browsers, like TextEncoder or BroadcastChannel or many other things, don't exist in Node. So one nice thing about Deno is that almost all the code you write for Deno will also work in a browser (unless you use "Deno.launchDroneAndFetchCoffee()" or whatever.
intelVISA 3y ago
I'm not familiar with the web space but from my untrained eye these sorts of projects are more like modernized V8 wrappers than runtimes in the traditional sense.
- dartos 3y ago
  If you were making a scriptable game, V8 would be like Lua. It handles the Lua language and some of the basic functionality of it, but beyond that you’d need to integrate it with ur engine.

wiseowise 3y ago

> I’ve been doing all kinds of JavaScript and TypeScript for a long time now without a runtime (I think) so pretty curious. Node and browser are both runtimes for your JS code.

skybrian 3y ago

V8 is a library that gets embedded in some larger program. It doesn't determine how imports work or any API's, and if you don't have any API's to call, there's not much you can do in JavaScript. A browser does all that, so that's the runtime. Similarly for Node's import resolution and its API's for doing I/O. You could think of it as all the code in the 'deno' or 'node' command other than V8 itself.

sfvisser 3y ago
Got it. Maybe I always naively assumed there is some shallow FFI layer and all the heavy lifting is done by some set of core standard libraries. Ideally portable to multiple environments.
- skybrian 3y ago
  There’s some of that. I/O in node is done by a C library called libuv [1]. It’s portable and it’s used by other languages too. Deno doesn’t use it, though. They use Rust ecosystem libraries like tokio. [2] [1] http://docs.libuv.org/en/v1.x/ http://docs.libuv.org/en/v1.x/ [2] https://choubey.gitbook.io/internals-of-deno/architecture/tokio https://choubey.gitbook.io/internals-of-deno/architecture/to...

goku12 3y ago

The additional thing that node, deno and even a browser supplies (aside from what V8 does) is an API layer and sandboxing features. So perhaps, 'the interaction layer', as you put it?

veidr 3y ago

I know what you mean. I feel like the term "execution environment" better describes it, but "runtime" has historical momentum in the JS world (I think), so changing it might cause other confusion. I think (probably) you've been doing your JS/TS in a "runtime" but that was probably either a.) the browser, or b.) Node.js. In the (pretty weird, IMHO) JS world, this notion of "runtime" amounts largely to what magical global variables are available. And then, what language features are available. Deno (properly, IMLHO) hides most of its "nonstandard" features behind one magic global variable: Deno. The rest of what it offers is "standard" which Deno (and all sane persons IMNSHO) interprets as "what the browser supports". Even that's fucked, in JS-world, because there are a bunch of browsers, and each one of them is like "yea woo I love standards, but fuck that standard". But browsers have a standard, more or less, it's just that all browsers implement only a subset of it. Still, to me, that's "the standard". So Deno implements its own subset of that standard (but they seem to try hard to implement as much as possible), and then it adds its own "Deno" global object for everything else (like local filesystem access, key-value database, etc that browsers don't support). An execution environment like Node hasn't traditionally prioritized compatibility with "the browser" and so instead it offers a bunch of top-level built-in things like "fs" or whatever, that you "require()" and then you can use them. And standard things that exist in al(most al)l browsers, like TextEncoder or BroadcastChannel or many other things, don't exist in Node. So one nice thing about Deno is that almost all the code you write for Deno will also work in a browser (unless you use "Deno.launchDroneAndFetchCoffee()" or whatever.

intelVISA 3y ago

I'm not familiar with the web space but from my untrained eye these sorts of projects are more like modernized V8 wrappers than runtimes in the traditional sense.

dartos 3y ago
If you were making a scriptable game, V8 would be like Lua. It handles the Lua language and some of the basic functionality of it, but beyond that you’d need to integrate it with ur engine.