There's also JCO for creating JS based WebAssembly components. It's based on StarlingMonkey which I believe is slightly faster than QuickJS under web assembly. https://github.com/bytecodealliance/jco

Benchmark numbers for request isolated JS hello world / React page rendering:

    JCO/wasmtime: 314µs / 13ms
    Bun process forking: 1.7ms / 8.2ms
    v8 isolate from snapshot: 0.7ms / 22ms
    TinyKVM: 52µs / 708µs
    Native with reuse 14µs / 640µs

(I suspect even if we are able to get TinyKVM into a state you'd feel comfortable with in the future it would still be an awkward fit for Datasette since nested virtualisation is not exposed on AWS EC2.)

> the whole point of WebAssembly is to solve this one problem.

For Wasm to be a secure sandbox, you have to assume a bug-free compiler/interpreter, which, alas, none of them really are. It's a somewhat easier problem than building a bug-free JavaScript runtime, but not by as much as you might expect, sadly.

> I want to build extension systems for my own apps such that users can run their own code or paste in code written by other people and have it execute safely. Similar to Shopify Functions: https://shopify.dev/docs/apps/build/functions

Ah, this is exactly the Workers for Platforms use case: https://developers.cloudflare.com/cloudflare-for-platforms/w...

And indeed, Shopify uses it: https://shopify.engineering/how-we-built-oxygen

(There's also the upcoming Dynamic Worker Loader API: https://developers.cloudflare.com/workers/runtime-apis/bindi...)

But it sounds like you really do want to self-host? I don't blame you, but that does make it tough. I'm not sure there's any such thing as a secure sandbox that doesn't require some level of monitoring and daily maintenance, sadly. (But admittedly I may be biased.)

You need more than a simple sandbox for what you describe. You also need to avoid infinite loops or other constructs from causing a DoS or similar, and if you are doing this with the intention of interacting with some other parts of a system then you need to think about how that interaction works and whether there is a way to execute something outside of that sandbox.

Even if you go with something backed by a full time team there is still going to be a chance you have to deal with a security issue in a hurry, maybe in the run up to Christmas. That is just going to come with the territory and if you don’t want to deal with that then you probably need to think about whether you really need a sandbox that can execute untrusted code.

I worked on a sandbox of Hermes that compiles the engine to wasm, and then converts the wasm to C (like Mozilla's RLBox). It exposes the same C++ API as Hermes so it is pretty convenient to drop in, and should be fairly secure.

It hasn't been updated in some time, but it should still be working, and can probably be brought up to date with some small effort: https://github.com/facebook/hermes/tree/static_h/API/hermes_...

EDIT: Reading some of your other comments, I should point out that this is more like a component of a possible solution. It does not attempt to prevent resource exhaustion or crashes due to corrupted internal state.

Wait, why not just actually use the Cloudflare Sandboxes product then? Is it too costly or something? Or you need to be able to run without a connection to their cloud?

https://developers.cloudflare.com/sandbox/

mquickjs shouldn't be escapable, in theory, given the memory model. I would do everything possible to avoid WASM, otherwise I'd just run V8.

What's wrong with V8?

You could also look at GraalJS. It's shipped as part of the Oracle Database, there's a security team, patching process etc. It's used in production by Amazon amongst others. It's got flexible sandbox features too.

https://www.graalvm.org/latest/reference-manual/embed-langua...

The way it's written is good for security as well:

https://medium.com/graalvm/writing-truly-memory-safe-jit-com...

Disclosure: I sit next to the GraalVM team.

The problem Flutter has is highly highly dependent on Google, from funding to development.

That it is also the only real use case for Dart also doesn’t help matters.

While I agree the technology is very good and in some cases superior it doesn’t have a path to stable funding, seemingly. Google laid off a big chunk of Dart and Flutter teams last year, and there is no Expo to pickup the slack.

While Meta could do the same for React Native, Expo has always been there to pick up the slack and it receives bigger community support from the community too. For example Shopify has a few great well maintained RN libs

Bun's original marketing used JSCore's superior performance as a main benefit over Node.js.[0]

Why would Google have more incentive than Apple to make the fastest engine? Safari being the fastest mobile browser is important to Apple.

If Google had a stronger incentive than Apple, we would have seen V8 being more performant by now.

[0]https://web.archive.org/web/20220724110148/https://bun.sh/

For a long time v8 was the fastest on a set of benchmarks but not on real world work load. That was the time when SpiderMonkey and JSC decided to go on a different path. I believe it was Mozilla that make the move first.

If we believe there is limit to everything, then the only sane conclusion would be v8 and JSC would both perform nearly the same with negligible difference in the long term. So choosing something that is fast, simple to integrate now makes a lot more sense.

Of course that is assuming memory usage, security and others being equal.

> Google has a lot more incentive than Apple to make the fastest engine

What are those incentives? I see no incentive for Google to make something fast.

I am not sure how "long term" you are thinking about. Making big architectural changes does not necessarily lead to better performance. JSC has been the fastest JS engine in the past 5-10 years as I remember. If google had a solution, they would have it now.

> Maybe the canvas operations are particularly slow on Firefox

That seems likely. WebRender (Firefox's GPU accellerated rendering backend) doesn't do vector rasterization. So Firefox rasterizes vectors using the CPU-only version of Skia and then uploads them to the GPU as textures. Apparently the upload process is often the bottleneck.

In contrast, Chrome uses (GPU-accelerated) Skia for everything. And Skia can render vector graphics directly into GPU memory (at least part of the rasterization pipeline is GPU accelerated). I would expect this to be quite a bit faster under load.

It's a known problem, but I hear that almost all of the Gecko graphics team's capacity beyond general maintenance is going towards implementing WebGPU.

---

SpiderMonkey is also now just quite a bit slower than V8 which may contribute.

The developers are busy ramming AI into it by management. This is probably never going to get looked into.

My results similar with M4 Pro (12 cores, 16 cores GPU), 24 GB RAM macOS 26.2 (the same benchmarks, I guess, https://browserbench.org/JetStream2.0/):

Firefox: 298.136

Safari: 425.762

Just the last test in this test suite:

> 3d-cube-SP > 3D cube rotation benchmark by Simon Speich. The original can be found on Simon's web page. Tests arrays and floating-point math in relatively short-running code.

gives the following results:

Firefox: 305.197

200 First 338.983 Worst 419.309 Average

Safari: 818.449

238.095 First 176.471 Worst 1957.237 Average

which shows that in this particular test, Safari is 2.5 times faster.

I don't know fast it would be if it was done iteratively. But Apple's implementation has negative implications for debuggability: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... .

V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also, imagine you have missing info from the error stack trace in production code running on NodeJS. that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.

The difference is loops don't normally have traces but function calls do.

Yes, It's called ShadowChicken, and it has negative implications for debuggability. To make debugging tolerable, JavaScriptCore added an (intentionally silly) mechanism called ShadowChicken: a shadow stack used by Web Inspector that can show a finite number of tail-deleted frames (they mention 128). It's has some tradeoff.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... .

https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-...

V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also imagine you have missing info from the error stack trace in production code running on NodeJS, that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.