Running JS on WASM is already pretty easy with quickjs, but it’s cool to see new entrants especially one in Rust.
My suggestion to the author: try to encapsulate your interpreter’s state completely in a data structure instead of relying on Rust’s call stack. That way your users can easily implement async and suspend/resume, coroutines etc. The annoying bit of QuickJS is that it uses the C stack so there’s no way to pause the VM and do something else in your C, and then resume later without abusing ASYNCIFY compiler pass or something.
try to encapsulate your interpreter’s state completely in a data structure
– JSRefs on Rust stack are exactly what prevents me from having a sane GC right now (I already had a draft of a GC when I discovered this problem). I’m going to overhaul the design and hide the implementation details in the crate and either have all external references accounted for, or make it impossible to leak them outside of a limited scope (using Rust borrow checker).
It’s a simple tree-walking JavaScript interpreter (roughly ES5, but many parts still missing and untested). It does not have garbage collection yet (I discovered the root tracing problem pretty late in the process), it does not have a lexical JavaScript parser (it’s offloaded to Esprima).
My initial goal was to get to a stage when it’s possible to run esprima.js in the interpreter itself. Now it’s mostly achieved: simple snippets of JavaScript can be parsed by an instance of Esprima inside the interpreter (loaded from a bundled JSON dump of its ESTree AST), but it still trips over missing methods of Array/String pretty often.
docs/TODO.org has a detailed list of (not yet) implemented features.
@dmytrish linked to their project in a reply to me on the not-a-runtime JS “runtime” post from the other day[1], and I thought it was super interesting to look at and see how things were being done.
Running JS on WASM is already pretty easy with quickjs, but it’s cool to see new entrants especially one in Rust.
My suggestion to the author: try to encapsulate your interpreter’s state completely in a data structure instead of relying on Rust’s call stack. That way your users can easily implement async and suspend/resume, coroutines etc. The annoying bit of QuickJS is that it uses the C stack so there’s no way to pause the VM and do something else in your C, and then resume later without abusing ASYNCIFY compiler pass or something.
–
JSRefs on Rust stack are exactly what prevents me from having a sane GC right now (I already had a draft of a GC when I discovered this problem). I’m going to overhaul the design and hide the implementation details in the crate and either have all external references accounted for, or make it impossible to leak them outside of a limited scope (using Rust borrow checker).I thought the rust but was the most interesting, but the page I linked to was “in wasm!”, so I figured I should include it.
Please note that this is my toy project inspired by Andreas Kling’s JavaScript videos. If you are looking for a more mature JavaScript runtime implementation in Rust, https://github.com/boa-dev/boa is much more advanced.
It’s a simple tree-walking JavaScript interpreter (roughly ES5, but many parts still missing and untested). It does not have garbage collection yet (I discovered the root tracing problem pretty late in the process), it does not have a lexical JavaScript parser (it’s offloaded to Esprima).
My initial goal was to get to a stage when it’s possible to run esprima.js in the interpreter itself. Now it’s mostly achieved: simple snippets of JavaScript can be parsed by an instance of Esprima inside the interpreter (loaded from a bundled JSON dump of its ESTree AST), but it still trips over missing methods of
Array/Stringpretty often.docs/TODO.org has a detailed list of (not yet) implemented features.
@dmytrish linked to their project in a reply to me on the not-a-runtime JS “runtime” post from the other day[1], and I thought it was super interesting to look at and see how things were being done.