[dead]
JavaScript engines zoo – Compare every JavaScript engine
71–80 of 97 posts
Re: JavaScript engines zoo – Compare every JavaScript engine
#72I got a question for everyone: as a web user , have you been affected by performance limitations of a particular JS engine? Have you switched browsers b/c of JS speed? My n=1 as a long time Firefox user is that performance is a non-issue (for the sites I frequent). I’m much more likely to switch browsers because of annoying bugs, like crashes due to FF installed as a snap. It honestly is pretty surprising, given that…
When Chrome first came out in 2008, it was noticeably faster than any competitors. Users with only moderate tech knowledge were switching in droves because it was faster. Part of this was that it had a process-per-tab model properly making use of multi core CPUs for the first time, but much of it was because V8 was fast.
The gap is not so big these days. JavaScriptCore, Spidermonkey, and V8 are all competent.
Re: JavaScript engines zoo – Compare every JavaScript engine
#73Earlier quoted context omitted.
To add some color to "workerd is not a hardened sandbox": workerd does not include any sandboxing layers other than V8 itself. If someone has a V8 zero-day exploit, they can break out of the sandbox. But putting aside zero-day exploits for a moment, workerd is designed to be a sandbox. That is, applications by default have access to nothing except what you give them. There is only one default-on type of access: publi…
Right - I trust workerd in the context of Cloudflare because I know it has a team of people who's job it is to keep it secure who are on-call 24/7. The problem I have is that I'm just one person and I don't want to be on call 24/7 ready to react to sandbox escapes, so I'm hoping I can find a solution that someone else built where they are willing to say "this is safe: you can feed in a string of untrusted JavaScript…
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.)
Re: JavaScript engines zoo – Compare every JavaScript engine
#74Earlier quoted context omitted.
https://github.com/bellard/mquickjs Featured recently on HN.
Yeah that (and full QuickJS) running inside WebAssembly do appear to be my best options. Here's my experiment running that one in WASM: https://github.com/simonw/research/tree/main/mquickjs-sandbo...
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.
Re: JavaScript engines zoo – Compare every JavaScript engine
#75Earlier quoted context omitted.
To add some color to "workerd is not a hardened sandbox": workerd does not include any sandboxing layers other than V8 itself. If someone has a V8 zero-day exploit, they can break out of the sandbox. But putting aside zero-day exploits for a moment, workerd is designed to be a sandbox. That is, applications by default have access to nothing except what you give them. There is only one default-on type of access: publi…
Right - I trust workerd in the context of Cloudflare because I know it has a team of people who's job it is to keep it secure who are on-call 24/7. The problem I have is that I'm just one person and I don't want to be on call 24/7 ready to react to sandbox escapes, so I'm hoping I can find a solution that someone else built where they are willing to say "this is safe: you can feed in a string of untrusted JavaScript…
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?
Re: JavaScript engines zoo – Compare every JavaScript engine
#76Earlier quoted context omitted.
> 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 wri…
Yeah my ideal is to have something that cleanly "pip installs" as a dependency such that users of my open source Python projects can self host tools that let them extend using arbitrary code, including code written by LLMs. I've been picking at this problem for a few years now! On the one hand I get why it's so hard. But it really feels like it should be possible to solve this in 2026 - executing arbitrary code in a…
Ah, in that context, why not just give the people workerd? People using & running OSS libraries are used to the fact that there might be vulns in libraries they're using, right?
Re: JavaScript engines zoo – Compare every JavaScript engine
#77Earlier quoted context omitted.
Yeah that (and full QuickJS) running inside WebAssembly do appear to be my best options. Here's my experiment running that one in WASM: https://github.com/simonw/research/tree/main/mquickjs-sandbo...
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.
Why avoid WASM?
Re: JavaScript engines zoo – Compare every JavaScript engine
#78genuine question, let us say you took the source code of every single engine you see here and feed it to all the 10000 llms and ask them to analyze the code, optimize every function the best way they see fit, make architectural changes as and when they see appropriate, what do you think will be the result from cutting edge models?
Re: JavaScript engines zoo – Compare every JavaScript engine
#79Earlier quoted context omitted.
Yeah my ideal is to have something that cleanly "pip installs" as a dependency such that users of my open source Python projects can self host tools that let them extend using arbitrary code, including code written by LLMs. I've been picking at this problem for a few years now! On the one hand I get why it's so hard. But it really feels like it should be possible to solve this in 2026 - executing arbitrary code in a…
Ah, in that context, why not just give the people workerd? People using & running OSS libraries are used to the fact that there might be vulns in libraries they're using, right?
Or put another way:
If Simon's users choose to self-host the open source version of his service, they are probably using it to run their own code, and so the sandbox security matters less, and workerd may be fine. The sandbox only matters when Simon himself offers his software as a service, which he could do using Workers for Platforms.
(But this is a self-serving argument coming from me.)
Re: JavaScript engines zoo – Compare every JavaScript engine
#80Earlier quoted context omitted.
Right - I trust workerd in the context of Cloudflare because I know it has a team of people who's job it is to keep it secure who are on-call 24/7. The problem I have is that I'm just one person and I don't want to be on call 24/7 ready to react to sandbox escapes, so I'm hoping I can find a solution that someone else built where they are willing to say "this is safe: you can feed in a string of untrusted JavaScript…
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/
I'm building software I want other people to be able to run themselves, I don't want to have to tell them to create a Cloudflare account as part of running that software.