[HN Gopher] Building a JavaScript Runtime using C
___________________________________________________________________
Building a JavaScript Runtime using C
Author : redbell
Score : 57 points
Date : 2025-10-07 22:18 UTC (4 days ago)
(HTM) web link (devlogs.xyz)
(TXT) w3m dump (devlogs.xyz)
| TheCleric wrote:
| I was a little disappointed that this was "just" a wrapper for
| JavaScriptCore.
| jesse__ wrote:
| 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..
| jakogut wrote:
| 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.
| jesse__ wrote:
| 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
| jakogut wrote:
| I wasn't trying to make any jabs, just an observation
| that getting outside of your comfort zone can be novel
| and interesting, even if it's mundane to people that
| commonly spend lots of time there.
| Minor49er wrote:
| 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
| trollied wrote:
| Yup. I clicked on it, based on the title, and expected a
| long-form article. Not a simple library utilisation post.
| curtisblaine wrote:
| 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.
| throwawaymaths wrote:
| iiuc its a runtime because the engine just dispatches one
| javascript microtask and returns to the runtime with a stack
| of remaining microtasks
| gr4vityWall wrote:
| 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.
| bryanrasmussen wrote:
| 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.
| yb303 wrote:
| This is not "Building from scratch" This is just using.
| Spivak wrote:
| Runtime is the glue between JS Engine and OS which is from
| scratch. Runtime embeds engine and lets engine talk to the
| outside world.
| throwawaymaths wrote:
| engines only execute one JS microtask at a time, you must run
| it in something, that's the runtime.
| lerp-io wrote:
| unpopular comment : v8 > JavaScriptCore.
| dunham wrote:
| 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).
| claytongulick wrote:
| 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/
| hackthemack wrote:
| 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).
| jhgb wrote:
| 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.
| ranger_danger wrote:
| > there's no claim being made that this was supposed to be a
| from-scratch implementation of Javascript
|
| That is exactly how I interpreted the title of the article.
| djmips wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| Duktape is also good for that I hear https://duktape.org/
| measurablefunc wrote:
| 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?
| WalterBright wrote:
| I wrote a JavaScript engine from scratch using C++ back in 2000.
|
| https://www.digitalmars.com/dscript/cppscript.html
|
| I later translated it to D:
|
| https://github.com/DigitalMars/DMDScript/tree/master/engine/...
|
| Github: https://github.com/DigitalMars/DscriptCPP
___________________________________________________________________
(page generated 2025-10-11 23:00 UTC)