Comments and formatting can account for that difference in LOC though... not always directly comparable. Haven't looked, but variances with different assembly bits can make a big difference too.
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 architecture than V8, and seeing the V8 team make big architectural changes as we speak seems to support it [1], but like I said, hopefully they will pay off long term
Because tech debt is real... V8 exists and likely isn't going to be completely displaced as a whole. That said, I can't speak for what are or aren't priorities for Google... I'd say they and Apple both have every incentive to give a good experience, and how far that is from the "best" experience will vary.
For a long time v8 was the fastest on a set of benchmarks but not on real world work load. That was the time when SpiderMonkey and JSC decided to go on a different path. I believe it was Mozilla that make the move first.
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.
And the faster that a page finishes rendering on an iphone, the faster that the cpu can idle, which hugely benefits battery life. That's a pretty strong motivation on Apple's side. I don't think the proposed motivation on google's side is stronger.
What are the marginal gains in business for them from the likely improvement of the runtime? It's not like the web (or: web-technology-based apps) don't capture a lot of time already.
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.
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.
> 3d-cube-SP
> 3D cube rotation benchmark by Simon Speich. The original can be found on Simon's web page. Tests arrays and floating-point math in relatively short-running code.
gives the following results:
Firefox: 305.197
200 First 338.983 Worst 419.309 Average
Safari: 818.449
238.095 First 176.471 Worst 1957.237 Average
which shows that in this particular test, Safari is 2.5 times faster.
And SpiderMonkey seems... not up there compared to the other 2