Comment by olliej
3 years 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.
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.
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.
You might find this interesting: https://github.com/svaarala/duktape/blob/master/doc/compiler...
JS runtime != JS engine
Runtime: - Chrome - Deno - Node - Bun
Engine: - V8 - JSC - SpiderMonkey - LibJS
That's a weird usage of the word "runtime" then. To me, the definition is closer to Wikipedia's definition of "runtime system" [0] and includes any interpreters, JITs, and any other language elements present while a program is running.
The runtime includes the engine (interpreter for example) and an environment, which could also include a standard library, bindings to the outside world and more.
For example, in the case of node, it's a runtime built around the v8 engine, using libuv for bindings.
It’s Javascript. Everything is weird - from the equality coercion to the package management to left padding text.
1 reply →
No.
The runtime is the combination of the execution engine, the garbage collector, and the environment.
V8, JSC, SpiderMonkey, LibJS, etc all provide all of those.
They all have APIs that let you (the embedder) a few new objects and functions, as it would be a useless embedding API otherwise. But that's all you're doing: adding some glorified callbacks to an existing runtime. You are in no way "rolling your own JS runtime".
To break it down:
Execution Engine: the part of the runtime that evaluates JS, an interpreter, jit, or some combination. That would be "Ignition" and "TurboFan" in V8, "LLInt" and "FTL" in JSC, "WarpMonkey" in SpiderMonkey.
Garbage Collector: the part of the runtime that supports object allocation and reclamation. "Orinoco" in V8, but not sure if given a separate marketing name in other runtimes.
The environment: this is all the builtin objects and functionality, things like the global object, the regex engine (note it's not a regex runtime because all it does find the start and stop sections of matches, the embedding environment is responsible for everything else), all those core things like the Object, Array, Math, Number, etc types, and all of their implementations and runtime functions. The Execution engine does not need any of those to be implemented, as to the engine there is essentially no distinction between those builtin things and anything else written in JS.
When you embed V8, JSC, LibJS, etc you are getting a full runtime, that can do a huge amount. You _might_ choose to use there APIs to add some new objects or or functions, but what you are doing is negligible, and certainly not "a runtime".
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#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/
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.
> 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().
Not to forget the engine Charka: https://github.com/chakra-core/ChakraCore
The only bit of the old Edge that had its source emancipated. It was/is? quite performant.
I expected some interesting content and left with a "import v8: Cargo edition" 'tutorial' is this really a good look for the ailing Deno?
Yes, this is more like "Roll your own JavaScript environment"
> 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.
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.
So Node is not a JS runtime?
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.
It is but the Node developers developers didn't roll their own JavaScript runtime.