[1] https://cdn-images-1.medium.com/max/2000/1*dnhO1M_zlmAhvtQY_...
It's been a bit, and I'm going from memory here, so forgive me if i'm wrong, but...
V8 is introducing a new "interpreter" mode to help here so that the page can start being interpreted ASAP and no JIT overhead needs to force the system to wait until it's done a first pass. And in the long run they want to pull out 2 of the JITs in their engine to simplify the process and speed up the first execution (along with reducing memory usage, and simplifying the codebase to allow for faster and easier additions and optimizations).
It's a great move, but it means that things are going to get slightly worse before they get better.
The "old" V8 had 3 compilers, "Fullcodegen", "crankshaft", and "turbofan" [0]. The current V8 has those 3 + Ignition [1], so it's just adding more on now. But over time they will be removing crankshaft and fullcodegen and it will leave them with a really clean and fast engine [2].
If anyone is interested, [3] is a fantastic talk on this and other plans they have for V8, and it's very accessible for those who don't know a thing about JS engines.
(sorry about the links to google sheets here, it's the only place I can seem to find the infographics)
[0] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...
[1] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...
[2] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...
[3] https://youtu.be/r5OWCtuKiAk
edit: Removed comment about edge, it was more assumption than anything.
I am not aware that Edge is "stupidly fast" on startup. Safari though, is indeed currently leading the field.
As you correctly outlined, V8 is indeed transitioning to a world with an interpreter+optimizing compiler only. If you are using Chrome Canary, there is a chance that you are already using the new pipeline :-).
Full disclosure: I work on the V8 team.
ECL and CLISP both settled on this model. CLISP started out as a bytecode interpreter and added GNU Lightning for native code generation. ECL started out as a source-to-source compiler to C and added a bytecode interpreter; both follow C calling convention as much as possible, at first for easy interop with C code and then for easy interop for the bytecode interpreter, which avoids the C++ interop problems mentioned in the talk.
How much of what's remaining is performance versus stability/correctness?
As for the Ignition+TurboFan setup, are you really that far along already?
Last I heard a few months ago it still sounded like it was gonna be a while before TurboFan was fast enough in most cases to be able to handle it.
If so that's awesome!
Granted, this isn't a strict apples-to-apples comparison, but the differences are so drastic and always in Apple's favour. That, combined with the actual, physical differences in speed of the processors on the phone itself, indicates that it's not just Safari.
Also that even the bitcode model is compiled at the store, instead of frying eggs on the device.
Doing real-time audio applications on Android is a pain, from the presentations I have watched, even with the NDK.
[0] They are always too busy saying, "Just use React".