81–90 of 97 posts
Earlier quoted context omitted.
> 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.
Faster page load times increases engagement with the web. More engagement on the web leads to more engagement with Google's ads.
All these JavaScript engines and it's still remarkably hard to find a robust solution for executing JavaScript from untrusted sources inside my own server-side applications. Every time I look I find repos that look promising at first but are either unmaintained or have a team or just one or two maintainers running them as a side project. I want my sandbox to be backed by a large, well funded security team working for…
How much are you ready to pay for a license?
genuine 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?
Earlier quoted context omitted.
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?
You're running JS (an 'interpreted', managed language) - it's already intentionally designed to be executed in a sandbox. Unless you provide hooks out to the host system, it can't do anything bad. With mquickjs, the untrusted code can't even overflow your heap or take too much execution time.
If you were running untrusted C or something, it would make more sense to add the WASM layer.
Earlier 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…
Earlier quoted context omitted.
Why avoid WASM?
Because what's the point? You're running JS (an 'interpreted', managed language) - it's already intentionally designed to be executed in a sandbox. Unless you provide hooks out to the host system, it can't do anything bad. With mquickjs, the untrusted code can't even overflow your heap or take too much execution time. If you were running untrusted C or something, it would make more sense to add the WASM layer.
I have enormous respect for Fabrice but mquickjs is only a few weeks old and I'm no way near skilled enough to audit his C code!
Running it in WASM feels a lot safer to me.
All these JavaScript engines and it's still remarkably hard to find a robust solution for executing JavaScript from untrusted sources inside my own server-side applications. Every time I look I find repos that look promising at first but are either unmaintained or have a team or just one or two maintainers running them as a side project. I want my sandbox to be backed by a large, well funded security team working for…
> I want my sandbox to be backed by a large, well funded security team How much are you ready to pay for a license?
Earlier quoted context omitted.
Because what's the point? You're running JS (an 'interpreted', managed language) - it's already intentionally designed to be executed in a sandbox. Unless you provide hooks out to the host system, it can't do anything bad. With mquickjs, the untrusted code can't even overflow your heap or take too much execution time. If you were running untrusted C or something, it would make more sense to add the WASM layer.
Mainly defence in depth. I have enormous respect for Fabrice but mquickjs is only a few weeks old and I'm no way near skilled enough to audit his C code! Running it in WASM feels a lot safer to me.
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…
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.
Earlier quoted context omitted.
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/