The benchmark at the bottom showing how far behind Firefox has fallen on JS performance is pretty telling. It confirms my own recent observation that Firefox is at least 3-6 times slower in practice for the particular app I'm working on.
fwiw, Chrome, Firefox and Safari have all been fairly competitive on the major performance benchmark (Octane) for a while, with jsc taking a bit to catch up to the others. Sunspider and Kraken are now relatively outdated because everyone is fast on them:
Octane is on the way out, so I have no doubt that the vendors will all pull close together on this new Apple benchmark set once they have time to optimize for it, since most of these benchmarks are cynical gaming anyway more than they are real applications. (Octane, which is culled from real webapps, had a glaring bug in one of its test cases for a while that happened to make v8 much faster at the cost of the test not actually doing real work.)
It's also silly to judge a browser's performance based on how fast bleeding-edge features are. Bleeding-edge features can't be fully/effectively optimized until there are real-world examples of how they are used.
P.S. it may be interesting to look at https://arewefastyet.com/#machine=36 and note that the JS runtime in MS's Edge is shockingly competitive on these benchmarks as well. You can't count anyone out of the race.
It's enough to make the startup feel slow (3-4 seconds of being unresponsive) and things like animations and drag and drop features to feel janky. Running a non-minified build (about 20MB of JS, minifies to about 1MB) also completely murders Firefox reducing it to a slideshow, making Firefox unusable for development, while Chrome works just fine.
For one thing, minification's impact is largely on parsing, so it shouldn't have any noticeable impact on anything other than startup time and memory usage (the compressed JS source for Function.toString will be a bit smaller if minified). If your app is really slower at runtime when not minified, again, something is wrong.
Is your application written in raw (non-transpiled) ES6 and heavily using generators, async, tail call opts etc in tight perf-sensitive loops that run on the main thread without yielding to the event loop? It's hard for me to come up with a scenario where you could see such a huge performance gap in a well-constructed application.
If computational performance is really important to you, then you're writing asm.js (or webassembly) and shipping that. All of the modern JS engines perform great on that sort of code and you simply cannot see a 3-6x gap there. So something weird is going on with your app that any vendor would be happy to fix if you sent them a repro (or just let them try out your app).
No wonder people move to other browsers instead.
Feel free to email me if you'd prefer not to share a link in a public HN comment. See my HN profile for my Mozilla email address.
I used to work on an app that was 5 to 10 times slower in v8 than in SpiderMonkey, was it a proof that v8 was slower than SpiderMonkey ? No, we were actually falling in a v8 slow path (using exceptions in a hot section of the code because babel was transpilling `for of` loops to something that used exceptions), after some profiling we found the culprit and fixed it.
When you hit a 5x differences in JavaScript speed, it's almost never a browser performance difference, it's a bug in this specific browser : you're probably hitting a slow paths in this engine and you can probably work around it (or report a bug and wait until they fix it).
[Edit: Actually two things: hot loops in the same function as a class definition, and derived classes that use "super".]
Chances are whatever you see on your app is a different issue. I'd be happy to profile and file bugs as needed if you can get me a link that shows the problem on your app.
1) If you have a class definition inside a function, that function doesn't get jitted. The functions in the class definition itself can still get jitted. 2) Class methods that use super don't get jitted at the moment.
So if your class definitions are not in the same function as your hot code and don't use super, you get fast paths. Otherwise some things will run in the interpreter.
The tracking bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=1167472 and https://bugzilla.mozilla.org/show_bug.cgi?id=1167472#c13 is what the above summary is based on.
These days Moco doesn't even try on mobile anymore (hint, there is no performance testing at all on arm in https://arewefastyet.com/#).
The desktop Firefox front-end didn't evolve so much during the FxOS days but these was not the same team either... and you would notice that key people leading Fx front end have changed since.
2) Apple is a mega-company which has a bajillion lines of business and produces hardware. The WebKit team is a tiny tiny tiny sliver of what Apple does and cares about; so its budget is probably a lot closer to Mozilla's.
Right... how does that make it any different?
Apple's not a finance company, or at least they weren't until they wound up with so much cash they had no actual present business needs for. If you're a hardware/software company that has so much extra money (billions) that you become your own 'hedge fund' to have something to do with it... yeah, you've got a lot of extra money. How much extra money? More than 500x the annual budget of Mozilla, yup.
I agree with jonas21 - for $400m a year you ought to be able to build an amazing browser.
I've had Firefox block more js/elements than Chrome and sometimes I think other bits of the page are busy waiting for some event that will never happen.
Also, all deployed sites and apps today are actually running ES5 transpiled from ES6.
I use lot of tabs and well chrome might start faster but if you have 30 tabs open it slows my whole computer. With firefox it seems all fine.