Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript engines zoo – Compare every JavaScript engine

zoo.js.org

Post reply on HN
Print view View original

61–70 of 97 posts

Re: JavaScript engines zoo – Compare every JavaScript engine

#61

Post by 360MustangScope »

tralarpa wrote: post #26
DarkFuture wrote: post #4

Earlier quoted context omitted.

Disappointing for Firefox for such lower performance. I just ran the JetStream2 benchmark and got: - Firefox: 159 score - Chromium: 235 score That's on latest Fedora Linux and Ryzen 3600 CPU.

Similar results here. I'm curious to know what the problem of Firefox is. For example, the 3d-raytrace-SP benchmark is nearly three times faster on Edge than on Firefox on my i7 laptop. The code of that benchmark is very simple and mostly consists of basic math operations and array accesses. Maybe the canvas operations are particularly slow on Firefox? This seems to be an example that developers should take a look at…

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

Re: JavaScript engines zoo – Compare every JavaScript engine

#62

Post by kentonv »

simonw wrote: post #60
kentonv wrote: post #58

Earlier 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…

> 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.)

Re: JavaScript engines zoo – Compare every JavaScript engine

#63

Post by neildhar »

simonw wrote: post #60
kentonv wrote: post #58

Earlier 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…

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.

Re: JavaScript engines zoo – Compare every JavaScript engine

#64

Post by aurareturn »

gurgunday wrote: post #20
aurareturn wrote: post #13

Earlier quoted context omitted.

That’s the promise of Bun - that it is faster because it uses JavascriptCore.

Bun is faster because it implements pretty much everything natively and just exposes them in JS, not because it uses JSCore I believe long term, V8 will become the undisputed champ again as Google has a lot more incentive than Apple to make the fastest engine, but this is just a wild guess of mine, and I'm biased being a Node.js Collaborator I've been hearing for a while that JSCore has a more elegant internal archit…

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/

Re: JavaScript engines zoo – Compare every JavaScript engine

#65

Post by aardvark179 »

simonw wrote: post #60
kentonv wrote: post #58

Earlier 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…

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.

Re: JavaScript engines zoo – Compare every JavaScript engine

#66

Post by simonw »

kentonv wrote: post #62
simonw wrote: post #60

Earlier 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…

> 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 way that constrains its memory and CPU time usage is a problem our industry solves in browsers and hosting platforms and databases and all sorts of other places, and has done for decades.

The whole LLM-assisted end-user programming thing makes solving this with the right developer affordances so valuable!

Re: JavaScript engines zoo – Compare every JavaScript engine

#68

Post by bflesch »

ivankra wrote: post #39
_alastair wrote: post #38

It’s fascinating to see so many implementations targeting the same thing, along with the crazy variation in runtime size. I’d love to see memory usage comparisons too but I suppose you’d need to establish what you’re actually measuring first. A few years ago I started work on a kind of abstraction layer that would let you plug Rust code into multiple different engines. Got as far as a proof of concept for JavascriptC…

I actually captured max RSS size while running benchmarks as a rough approximation, but it's not exposed anywhere. If you go to the repo, you can run `./bench/compare -f rss_mb -lT bench/amd64/*.json` to see a table in the terminal. No big surprises there, Java engines (Rhino, Nashorn, GraalJS) are most memory-hungry.

thanks for your work!

Re: JavaScript engines zoo – Compare every JavaScript engine

#69

Post by nicoburns »

tralarpa wrote: post #26
DarkFuture wrote: post #4

Earlier quoted context omitted.

Disappointing for Firefox for such lower performance. I just ran the JetStream2 benchmark and got: - Firefox: 159 score - Chromium: 235 score That's on latest Fedora Linux and Ryzen 3600 CPU.

Similar results here. I'm curious to know what the problem of Firefox is. For example, the 3d-raytrace-SP benchmark is nearly three times faster on Edge than on Firefox on my i7 laptop. The code of that benchmark is very simple and mostly consists of basic math operations and array accesses. Maybe the canvas operations are particularly slow on Firefox? This seems to be an example that developers should take a look at…

> 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.

Post reply on HN