Live data from Hacker News

JavaScript engines zoo – Compare every JavaScript engine

zoo.js.org

21–30 of 97 posts

Re: JavaScript engines zoo – Compare every JavaScript engine

#22

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…

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

Re: JavaScript engines zoo – Compare every JavaScript engine

#23
post #22

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…

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

Re: JavaScript engines zoo – Compare every JavaScript engine

#24
post #22

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…

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

A significant part of Google’s business (Ads, YouTube, Workspace) runs inside a browser, so if the web is slow, Google loses money

Re: JavaScript engines zoo – Compare every JavaScript engine

#25
post #10

I assume the 98% compatibility on ES6 for V8 is because they don't have tail call optimisation?

Maybe because with tail call optimization you wouldn't have a proper stack trace?

I never understood this complaint. You won’t get a “loop trace” when you convert your tail calls into an iterative algorithm. And your code will be less readable to boot.

Re: JavaScript engines zoo – Compare every JavaScript engine

#26
post #2

This is super cool, I didn't know JavaScriptCore consistently outperformed V8 And SpiderMonkey seems... not up there compared to the other 2

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.

Re: JavaScript engines zoo – Compare every JavaScript engine

#27
post #10

Earlier quoted context omitted.

Maybe because with tail call optimization you wouldn't have a proper stack trace?

I never understood this complaint. You won’t get a “loop trace” when you convert your tail calls into an iterative algorithm. And your code will be less readable to boot.

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

Re: JavaScript engines zoo – Compare every JavaScript engine

#28

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…

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.

Re: JavaScript engines zoo – Compare every JavaScript engine

#29
post #10

Earlier quoted context omitted.

Maybe because with tail call optimization you wouldn't have a proper stack trace?

Supposedly, although the team at Apple were able to implement it. I think they had some oddly named technology like Chicken which created a shadow stack trace? Half remembered.

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.

Post reply on HN