https://github.com/fatcerberus/minisphere/issues/153I've spent some time staring at JS engines recently, looking at compatibility, performance, and usability.
In addition to Spidermonkey (SM) and V8 I've also looked at Apple's Javascriptcore (JSC_ and I've taken a quick look at Microsoft's Chakracore (CC).
As far as I can see none of them run TypeScript natively (suggestion from your issue log above) that is unless I'm missing something the TypeScript benchmark some of them show is the speed of compiling typescript with the javascript typescript compiler.
PerformanceDifferent ones are better for different things. V8 seems to get the best results out of javascript that's written for readability not speed, whilst javascriptcore gets the worst results from such code. Spidermonkey comes out in the middle. flipping to code that has been written for speed and uses optimisation tricks javascriptcore jumps to the lead, outperforming V8 and spidermonkey by significant margins in some cases. Microsoft's ChakraCore seems to generally get the worst results on most benchmarks though there are a few outlying positives. I note that even bad results on the benchmarks = 10 * faster than miniSphere's current performance; the good results on the benchmarks are 70 * faster or more.
I note that from the tests I did it looks like far more effort has gone into optimising V8 and JSC performance than CC and SM, presumably as JSC is now used in a lot of IOS games and V* is used in node.js and probably android apps.
Compatibility with ES6They're all pretty good JSC gets 99%, SM and v8 both get 97% and CC gets 96.
http://kangax.github.io/compat-table/es6/Garbage CollectionCC: uses parallel processing to have garbage collection always happening rather than pausing for it
V8: incremental garbage collection but stops code execution when doing it
SM: no idea what it does - only documentation on GC in SM I can find says at the top that it (the documentation) is out of date and wrong
JSC: uses parallel processing to avoid stopping main thread for GC
APIs:JSC and CC both appear to have pure C apis available. (JSC also has an objective C api but it's a wrapper around the C api and can be safely ignored).
V8 and Spidermonkey both have C++ apis as the only option.
Documentation:V8: good documentation
CC: good documentation
SM: mixed documentation - wiki with loads of out of date content, though the key information for how to use it is there
JSC: mixed documentation - lots of focus on the objective C wrapper api rather than C, also most articles assume that any developer using it is targeting IOS
Licenses:V8: BSD
CC: MIT
SM: MPL2
JSC: LGPL
All of these seem ok to me as long as the source is kept separate from the miniSphere source.
ConclusionConsidering the potential to avoid needing a C wrapper around C++ I think that CC or JSC would be nicer options than V8 or SM, then based on benchmark performance I think that JSC just wins.
Anyway comparing these was a nice bit of fun, now I need to finish my collision detection...