Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
quickjs-emscripten
Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> So how does this work? Before the code is deployed, as part of a build step, we run the JS code using the JS engine to the end of initialization.
I also did basically this exact same thing for Go [0] when I realized their initialization in WASM was very heavy[1]. Basically I ran up until the real Go main started which includes a ton of runtime package/data initialization, and took a snapshot of the data and baked it back into the WASM and removed all the pre-main code. Granted this was years ago so I don't know if it still works on generated code today, but the idea is the same.
I think languages compiling to WASM, if they can, should run their initialization code and snapshot the data. A lot of people don't realize the number of init instructions to bootstrap a runtime these days. Go alone has thousands of instructions just to initialize the unicode tables.
0 - https://github.com/cretz/go-wasm-bake
It should probably be named "Making JavaScript to startup fast on WebAssembly", since the runtime speed is not really improved by the approach they exposed.
Besides that I think Wizer [1] is both an elegant and a simple solution to speed up startup speed with Wasm.
[1] - https://github.com/bytecodealliance/wizer#using-wizer-as-a-l...
The third and fourth paragraphs of the article address this question, but there are standalone WASM runtimes, including the one created by the OP:
https://github.com/bytecodealliance/wasmtime
These techniques are also (according to the article) potentially applicable to running other dynamic languages within WASM runtimes.
This sound tempting.. I'm building an interpreter (https://tablam.org) ad one of the reason is the interpreters are better for exploration/repls and such.
This looks like it will fix a major point: I could compile everything that is typed and left the rest for runtime.
I'm wondering how much easier could be the life if I compile to WASM to be run on my host...
One reason to use WASM to run JS, even in a browser, is to allow for interruptible execution of untrusted JS code. I built a library for this (1.2mb) that uses Emscripten to build QuickJS to WASM. I know of a company using my library to implement "plugin"/user-scripting using my library.
https://github.com/justjake/quickjs-emscripten#quickjs-emscr...
I wonder if the new Wizer component can be used by other projects in the WebAssembly space, e.g. Wasmer?
https://github.com/wasmerio/wasmer
(Haven't fully grasped how they're different from wasmtime, but I think they've spend more effort on embedding the runtime into other languages)
I haven’t tried but I’m pretty sure you can change variable values. Aside from it being Linux-only I haven’t encountered the CPU challenges. VM incompatibilities are a different story as I generally only ever run directly on metals when debugging. That being said, it looks like it does work (at least if you have sufficiently new software bits) so may be worth giving it another go: https://github.com/rr-debugger/rr/issues/2806