I don't understand what the goal is here. Honest question, not a criticism. Can someone please explain. Is the intention to have node work on multiple Javascript engines like spidermonkey? I can see why Chakra developers could want this but as a developer using node I don't see how I would benefit.
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]
And that was just the first thing off the top of my head, there are tons of other little performance things that many people consider a "JavaScript thing" instead of a "V8 thing"
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.
> it keeps falling behind on their list because not many people are using it.
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.
Yes, you need to account for that, and potentially make the decision that you should investigate targeting a different engine as the one you develop against. Your infrastructure should absolutely not be set in stone, and this includes looking at different compilers, different javascript engines, and different operating systems. If the most straightforward way of writing your code involves lots of try/catch blocks, then it sounds reasonable that you should target an engine that provides better speed for try/catch blocks.
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.
