I put a link in another comment to last week's discussion on the topic. But my main concern is developers writing code that tries to bend around then V8 implementation, even if it's not required by the language.
One great example from that thread was about try/catch:
"For example, a try/catch in V8 triggers deoptimization for the entire function it's in, while it might not in other engines. So this leads to many developers avoiding try/catch in performance critical code. This ends up with them avoiding it in general usage, which means that now "avoiding try/catch" is considered a general purpose performance tip in javascript, even though it might only apply to one engine (and the v8 team has expressed interest in trying to stop that deopt)"[0]
"It is a good example actually. Chakra does fully optimize functions with try/catch. Caveat: we don't optimize try/finally yet... Disclaimer: I work for MSFT on Chakra."[1]
"try/catch has pretty much no runtime overhead in SpiderMonkey unless an actual exception is thrown."[2]
[0] - https://news.ycombinator.com/item?id=10896729
You are just turning V8 into the new IE6 by adapting to it.
(Although, in reality, you probably won’t be able to do this, and will end up having to support the non-standard behaviour of V8.)
try/catch just isn't supported by V8's Crankshaft so some people avoid putting it in potentially hot code.
That's like not using CSS3 because IE6 doesn't support it.
Sure, some users of an antiquated browser will not get the full performance, but I have no sympathy for them.
If something doesn't work on Firefox, it's always "just switch to Chrome, our site only works on Chrome". If it doesn't work on Chrome, all hell breaks loose.
V8 has expressed interest in fixing the try/catch deopt, but it keeps falling behind on their list because not many people are using it.
Most people aren't using it because V8 (and in some minds, mine included until 5 days ago, all of Javascript) doesn't optimize it.
It's a bit of a catch 22, and having alternate engines where that deopt doesn't happen can be the way out.
Basically having an alternate engine makes sure that stuff like this doesn't become permanent. You'll probably avoid try/catch in performance code for the near future (and i'll most likely do it as well), but the hope is that multiple implementations will force V8 to fix that issue (if it can be called that) at some point and eventually this little bit of optimization will no longer be necessary.
How can that be true? try/catch is as common a JS idiom as a for loop.
This causes significant trouble all over React and many other libraries, as many hot areas of code are covered in try/catches to ensure developer error doesn't blow the whole render. Optimizing it could lead to pretty serious performance gains.
Why? Switch out V8 for ChakraCore. Having multiple engines means you, as a developer, get to pick the right tool for the job. That's not always V8.
Microsoft is trying to get into the whole IoT hype. This would help them a lot.
It also means they can write servers on Azure that don't need to be able to run V8.
Mostly windows store apps though.
Hopefully this will reduce the necessity to have a non-Windows machine around. That aspect has made things tedious for us.
Disclaimer: I work on V8
EDIT: 92% reported for "Version 50.0.2626.0 canary (64-bit)"
nice job!