JavaScript engines zoo – Compare every JavaScript engine
21–30 of 97 posts
Re: JavaScript engines zoo – Compare every JavaScript engine
#22Earlier 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…
What are those incentives? I see no incentive for Google to make something fast.
Re: JavaScript engines zoo – Compare every JavaScript engine
#23Earlier 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.
Re: JavaScript engines zoo – Compare every JavaScript engine
#24Earlier 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.
Re: JavaScript engines zoo – Compare every JavaScript engine
#25I 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?
Re: JavaScript engines zoo – Compare every JavaScript engine
#26This 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.
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
#27Earlier 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.
Re: JavaScript engines zoo – Compare every JavaScript engine
#28Earlier 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…
Re: JavaScript engines zoo – Compare every JavaScript engine
#29Earlier 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.
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.