5 ms·

This is not any kind of "rolling your own JS runtime". This is "use our framework to use v8 from rust". What an obnoxious title. v8 is a JS runtime. JSC is a J

by olliej 4y ago

This is not any kind of "rolling your own JS runtime". This is "use our framework to use v8 from rust". What an obnoxious title. v8 is a JS runtime. JSC is a JS runtime. SpiderMonkey is a JS runtime. All of these are embeddable and have usable APIs. If all you are doing, is linking to a JS runtime, and then using it, you aren't "rolling your own runtime". If you want to roll your own JS runtime go look at how the LibJS folk in serenity did it - they did it without corporate backing and despite that I believe LibJS is fairly complete even with the new draft language features, albeit lacking a decade or so of performance optimizations.

jchw 4y ago
Yeah unfortunately as pessimistic as it seems I must agree, this title is disappointing to me. I'd love to see a series discussing the ins and outs of even just tiny segments of implementing ECMA262, as there's quite a lot of interesting nuance that has come up over the years. I guess the difference is runtime vs perhaps interpreter, but it's definitely ambiguous.
- olliej 3y ago
  V8, JSC, etc have an interpreter (or JIT, or what have you), but they also include everything else: the GC, the standard library, the standard and core objects. e.g. the full runtime. Adding a couple of functions to an existing runtime is not rolling your own runtime.
- userbinator 4y ago
  You might find this interesting: https://github.com/svaarala/duktape/blob/master/doc/compiler.rst https://github.com/svaarala/duktape/blob/master/doc/compiler...
deleted 4y ago
[deleted]
intelVISA 4y ago
I expected some interesting content and left with a "import v8: Cargo edition" 'tutorial' is this really a good look for the ailing Deno?
paulddraper 4y ago
Yes, this is more like "Roll your own JavaScript environment"
lucacasonato 4y ago
JS runtime != JS engine Runtime: - Chrome - Deno - Node - Bun Engine: - V8 - JSC - SpiderMonkey - LibJS
- btown 4y ago
  Specifically, a runtime (IMO) is the set of variables and their associated functionality that exist in the global scope, or are expected to be importable in a predictable and standardized way. Part 2 of this series, for instance, shows the instantiator of the V8 engine (via deno_core, a runtime-less wrapper as explained in Part 1) implementing a simplified fetch API with some trivial JS and the bulk of the logic in Rust: https://deno.com/blog/roll-your-own-javascript-runtime-pt2#implementing-fetch https://deno.com/blog/roll-your-own-javascript-runtime-pt2#i... - this would then be available to any code executing in their custom JS environment. This is useful even outside of creating a full Node-style implementation; for instance, Cloudflare created a locked-down runtime (a reasonable subset of the browser runtime) for v8 isolates for their workers: https://developers.cloudflare.com/workers/runtime-apis/ https://developers.cloudflare.com/workers/runtime-apis/ It's super cool to know this stuff as it lets you consider (when appropriate!) using JS as a way to accept Turing-complete user-submitted logic rather than just accepting, say, JSON configs, while limiting the surface with which it can interact with your system.
  - olliej 4y ago
    > Specifically, a runtime (IMO) is the set of variables and their associated functionality that exist in the global scope, or are expected to be importable in a predictable and standardized way. All of which is provided by V8 in this example. The global object, math object, "Object" in general, Arrays, etc are all the runtime. All this tutorial series on embedding V8 is doing is instantiating an existing runtime environment and adding using the APIs to insert a few new APIs. All together you might say you've got a custom runtime as you have the baseline "JS runtime" + some new APIs and that's clearly a new runtime environment that is distinct from the JS environment on a web page, vs. the one in a worker, vs. in node, etc. But that is at best "extending a runtime", not "rolling your own". Using the embedding APIs provided by a JS runtime as documented and intended, is not "rolling your own". By that definition I could make an app, embed a WebView, and claim I rolled my own browser runtime, which I would hope is more clearly absurd. Or I could "roll my own Command-line" by reading a string from a user, prepending some commands, and then passing it to system().
pier25 4y ago
So Node is not a JS runtime?
- olliej 3y ago
  V8 provides a JS runtime. Node uses the V8 C++ APIs to add additional functions and objects to that runtime. So Node has a specific JS runtime environment, just as browsers have a specific JS runtime environment (and Workers have another), etc. All of these environments are extending the runtime environment provided by their underlying JS runtime, they're not all providing their own stdlib implementations, they're not providing their own implementations of arrays, objects, global object, etc.
- quikoa 4y ago
  It is but the Node developers developers didn't roll their own JavaScript runtime.
pdpi 4y ago
> v8 is a JS runtime. JSC is a JS runtime. SpiderMonkey is a JS runtime. V8, JSC and SpiderMonkey have no way to interact with the outside world. Without some supporting structure, running JavaScript does anything other than being an over-engineered space heater. It's that supporting structure — the runtime — that allows you to do anything useful. Visual Studio Redistributables for C++ is a famous case of a runtime that doesn't involve an interpreter.
- olliej 3y ago
  You're right an interpreter is not a runtime. However V8, JSC, SM, ... aren't just providing you an execution engine. E.g. they are providing all the core objects, APIs, etc that are equivalently provided by the "Visual Studio Redistributables for C++" which you seem happy to call a runtime. The lack of direct IO is irrelevant. You can take any of these libraries, and execute arbitrary JS, and then display the output (Serenity's spreadsheet uses LibJS for equation cells IIRC). E.g. JS that runs and uses the "runtime environment" to do things. Your particular use case may benefit from exposing some additional APIs to JS, and all these libraries allow you to do that. But exposing, for example, printf to a full JS runtime environment does not mean you've made a runtime. The belief that for something to be a "runtime" it must have built in IO routines me that no generally usable scripting environment could be a runtime.

by olliej 4y ago

jchw 4y ago

Yeah unfortunately as pessimistic as it seems I must agree, this title is disappointing to me. I'd love to see a series discussing the ins and outs of even just tiny segments of implementing ECMA262, as there's quite a lot of interesting nuance that has come up over the years. I guess the difference is runtime vs perhaps interpreter, but it's definitely ambiguous.

olliej 3y ago
V8, JSC, etc have an interpreter (or JIT, or what have you), but they also include everything else: the GC, the standard library, the standard and core objects. e.g. the full runtime. Adding a couple of functions to an existing runtime is not rolling your own runtime.
userbinator 4y ago
You might find this interesting: https://github.com/svaarala/duktape/blob/master/doc/compiler.rst https://github.com/svaarala/duktape/blob/master/doc/compiler...

deleted 4y ago

[deleted]

intelVISA 4y ago

I expected some interesting content and left with a "import v8: Cargo edition" 'tutorial' is this really a good look for the ailing Deno?

paulddraper 4y ago

Yes, this is more like "Roll your own JavaScript environment"

lucacasonato 4y ago

JS runtime != JS engine Runtime: - Chrome - Deno - Node - Bun Engine: - V8 - JSC - SpiderMonkey - LibJS

btown 4y ago
Specifically, a runtime (IMO) is the set of variables and their associated functionality that exist in the global scope, or are expected to be importable in a predictable and standardized way. Part 2 of this series, for instance, shows the instantiator of the V8 engine (via deno_core, a runtime-less wrapper as explained in Part 1) implementing a simplified fetch API with some trivial JS and the bulk of the logic in Rust: https://deno.com/blog/roll-your-own-javascript-runtime-pt2#implementing-fetch https://deno.com/blog/roll-your-own-javascript-runtime-pt2#i... - this would then be available to any code executing in their custom JS environment. This is useful even outside of creating a full Node-style implementation; for instance, Cloudflare created a locked-down runtime (a reasonable subset of the browser runtime) for v8 isolates for their workers: https://developers.cloudflare.com/workers/runtime-apis/ https://developers.cloudflare.com/workers/runtime-apis/ It's super cool to know this stuff as it lets you consider (when appropriate!) using JS as a way to accept Turing-complete user-submitted logic rather than just accepting, say, JSON configs, while limiting the surface with which it can interact with your system.
- olliej 4y ago
  > Specifically, a runtime (IMO) is the set of variables and their associated functionality that exist in the global scope, or are expected to be importable in a predictable and standardized way. All of which is provided by V8 in this example. The global object, math object, "Object" in general, Arrays, etc are all the runtime. All this tutorial series on embedding V8 is doing is instantiating an existing runtime environment and adding using the APIs to insert a few new APIs. All together you might say you've got a custom runtime as you have the baseline "JS runtime" + some new APIs and that's clearly a new runtime environment that is distinct from the JS environment on a web page, vs. the one in a worker, vs. in node, etc. But that is at best "extending a runtime", not "rolling your own". Using the embedding APIs provided by a JS runtime as documented and intended, is not "rolling your own". By that definition I could make an app, embed a WebView, and claim I rolled my own browser runtime, which I would hope is more clearly absurd. Or I could "roll my own Command-line" by reading a string from a user, prepending some commands, and then passing it to system().

pier25 4y ago

So Node is not a JS runtime?

olliej 3y ago
V8 provides a JS runtime. Node uses the V8 C++ APIs to add additional functions and objects to that runtime. So Node has a specific JS runtime environment, just as browsers have a specific JS runtime environment (and Workers have another), etc. All of these environments are extending the runtime environment provided by their underlying JS runtime, they're not all providing their own stdlib implementations, they're not providing their own implementations of arrays, objects, global object, etc.
quikoa 4y ago
It is but the Node developers developers didn't roll their own JavaScript runtime.

pdpi 4y ago

> v8 is a JS runtime. JSC is a JS runtime. SpiderMonkey is a JS runtime. V8, JSC and SpiderMonkey have no way to interact with the outside world. Without some supporting structure, running JavaScript does anything other than being an over-engineered space heater. It's that supporting structure — the runtime — that allows you to do anything useful. Visual Studio Redistributables for C++ is a famous case of a runtime that doesn't involve an interpreter.

olliej 3y ago
You're right an interpreter is not a runtime. However V8, JSC, SM, ... aren't just providing you an execution engine. E.g. they are providing all the core objects, APIs, etc that are equivalently provided by the "Visual Studio Redistributables for C++" which you seem happy to call a runtime. The lack of direct IO is irrelevant. You can take any of these libraries, and execute arbitrary JS, and then display the output (Serenity's spreadsheet uses LibJS for equation cells IIRC). E.g. JS that runs and uses the "runtime environment" to do things. Your particular use case may benefit from exposing some additional APIs to JS, and all these libraries allow you to do that. But exposing, for example, printf to a full JS runtime environment does not mean you've made a runtime. The belief that for something to be a "runtime" it must have built in IO routines me that no generally usable scripting environment could be a runtime.