That's not the point I was addressing. It's obviously true that mobile is slower than desktop by a factor of 5-10x. However, the author uses Sunspider as a metric to claim that "JS engines haven't really gotten all that much better since 2008".
That's not true at all.
On benchmarks like Kraken and Octane, which actually take multiple seconds to run instead of just milliseconds, both V8 and SpiderMonkey have improved significantly even just over the past year.
Speaking for SpiderMonkey (only because that's the engine I'm more familiar with), we've bumped Kraken by 20-25%, and we've bumped Octane by around 50%.
On real-world app code like pdfjs, and gbemu.. we've improved performance by 2-3x over the last year.
JS has gotten significantly faster over the last couple of years, and we're working quite hard on making it faster yet.
I think what he is saying is that your work is in vain because it doesn't increase performance by 10x or more and that such small increases are nice but not nice enough to make it worthwhile to use javascript.
The 5-10x difference mentioned is the difference in raw hardware speed between mobile CPUs and desktop CPUs, not a reference to JS speed vs native speed.
JS speed as compared to native depends heavily on the nature of the code being executed, how type-stable it is, how polymorphic it is, what its allocation behaviour is like, and a number of other factors.
That's not true at all.
On benchmarks like Kraken and Octane, which actually take multiple seconds to run instead of just milliseconds, both V8 and SpiderMonkey have improved significantly even just over the past year.
Speaking for SpiderMonkey (only because that's the engine I'm more familiar with), we've bumped Kraken by 20-25%, and we've bumped Octane by around 50%.
On real-world app code like pdfjs, and gbemu.. we've improved performance by 2-3x over the last year.
JS has gotten significantly faster over the last couple of years, and we're working quite hard on making it faster yet.