This could useful to reference for when you want to put a JavaScript interpreter in your own custom software. For example I've seen JavaScript used for console game UI systems.
How about a formally verified runtime that takes the JS spec & constructs a runtime by converting the spec w/ incremental & verifiable transformations into an executable runtime?
I guess I would like to see defining your global object in a real use case and adding some functions to your global object that make sense, which admittedly once you ask someone to do the creative work of making a use case that is sensible as they start implementing it they might find it is more useful to complete the implementation of that use case rather than releasing a starter tutorial.
For those who would like a true "from scratch" implementation of JavaScript, Fabrice Bellard's QuickJS [1] is clean, readable and approachable. It's a full implementation of modern JavaScript in a straightforward project, not nearly as complex or difficult as V8.
To be fair, there's no claim being made that this was supposed to be a from-scratch implementation of Javascript. Just an equivalent to Deno/Node which don't have their own implementation of Javascript either.
Agreed. It contradicts the whole "from scratch" idea. The article even has an engine implementation section where it just calls JavaScriptCore as you mentioned. It's a cool wrapper, but a misleading and disappointing article
Yeah, I was expecting a lot more than "I glued some libraries together in C!", especially when the author is claiming 'from scratch'. Seems like a somewhat disingenuous title if you ask me..
I suppose when your accustomed level of abstraction is interpreted languages like JavaScript, and "the web", "gluing some libraries together in C" is a somewhat novel and interesting endeavor.
To be fair, all commercial non-browser runtimes (node, bun, deno) are "just" wrappers of V8 or JSC. Some more experimental ones are "just" wrappers of QuickJS and other less known engines.
In general, yes, although it's nice to have more than one javascript implementation. And one advantage of JSC is that it implements tail call optimization (per the ES6 spec).
I wrote my own language that targeted javascript. When I made my language self-hosting, I initially used `bun` (based on JSC), so I wouldn't have to implement a tail call transformation myself. It was expedient.
My goal was to run in a browser, so I did eventually add that transformation and found that my compiler was 40% faster running in node (based on v8).
This could useful to reference for when you want to put a JavaScript interpreter in your own custom software. For example I've seen JavaScript used for console game UI systems.
How about a formally verified runtime that takes the JS spec & constructs a runtime by converting the spec w/ incremental & verifiable transformations into an executable runtime?
This is not "Building from scratch" This is just using.
Runtime is the glue between JS Engine and OS which is from scratch. Runtime embeds engine and lets engine talk to the outside world.
engines only execute one JS microtask at a time, you must run it in something, that's the runtime.
I guess I would like to see defining your global object in a real use case and adding some functions to your global object that make sense, which admittedly once you ask someone to do the creative work of making a use case that is sensible as they start implementing it they might find it is more useful to complete the implementation of that use case rather than releasing a starter tutorial.
For those who would like a true "from scratch" implementation of JavaScript, Fabrice Bellard's QuickJS [1] is clean, readable and approachable. It's a full implementation of modern JavaScript in a straightforward project, not nearly as complex or difficult as V8.
[1] https://bellard.org/quickjs/
To be fair, there's no claim being made that this was supposed to be a from-scratch implementation of Javascript. Just an equivalent to Deno/Node which don't have their own implementation of Javascript either.
QuickJS is amazing. You can put in javascript code, run it through QuickJS and make little binary utilities to run on their own.
Someone took QuickJS and put it in wasm so you can run QuickJS in the browser or in node.
https://github.com/justjake/quickjs-emscripten
Fabrice Bellard is on another planet when it comes to programming. He also wrote FFmpeg and QEMU (among other things).
I was a little disappointed that this was “just” a wrapper for JavaScriptCore.
Although not intuitive, it's common to call that the 'runtime' in the JS world, while V8 and JSC would be called 'JS engines'.
Deno used similar wording in a tutorial for creating your own JS runtime using Rust and V8 bindings: https://deno.com/blog/roll-your-own-javascript-runtime
IMO the tutorial is still cool nonetheless, it's a fun subject.
Agreed. It contradicts the whole "from scratch" idea. The article even has an engine implementation section where it just calls JavaScriptCore as you mentioned. It's a cool wrapper, but a misleading and disappointing article
Yeah, I was expecting a lot more than "I glued some libraries together in C!", especially when the author is claiming 'from scratch'. Seems like a somewhat disingenuous title if you ask me..
I suppose when your accustomed level of abstraction is interpreted languages like JavaScript, and "the web", "gluing some libraries together in C" is a somewhat novel and interesting endeavor.
I bit my tongue and decided to hold that jab at JavaScript programmers, but yeah, I think that's exactly what were looking at here
To be fair, all commercial non-browser runtimes (node, bun, deno) are "just" wrappers of V8 or JSC. Some more experimental ones are "just" wrappers of QuickJS and other less known engines.
iiuc its a runtime because the engine just dispatches one javascript microtask and returns to the runtime with a stack of remaining microtasks
unpopular comment : v8 > JavaScriptCore.
In general, yes, although it's nice to have more than one javascript implementation. And one advantage of JSC is that it implements tail call optimization (per the ES6 spec).
I wrote my own language that targeted javascript. When I made my language self-hosting, I initially used `bun` (based on JSC), so I wouldn't have to implement a tail call transformation myself. It was expedient.
My goal was to run in a browser, so I did eventually add that transformation and found that my compiler was 40% faster running in node (based on v8).