Hacker News Reader

Comment by pachydermic | Hacker News Reader

I think the claim was that arrays were too slow on Firefox and that's why it's Chrome only right now. Take that for what you will, but I think that was their claim.

View on HN

That was an easy example a gave of one of the minor hiccups, and it wasn't Arrays, but Sparse Arrays, which we were abusing. It's a case where using standard APIs, not proprietary APIs, leads to gotchas because of implementation differences between VMs, which normally don't manifest themselves in smaller apps, but do in large sophisticated apps.

The real blocking issue is very bad rendering performance, but that has been worked on for months now and you should see the results soonish. That's harder to illustrate in an HN thread. I've still got scars from the last discussion on this, so I'd advise people go read those old HN threads for insight. :)

What are you doing that makes performance that bad? It sounds like GWT is generating bad code...

It's nothing to do with JS code execution, the problem is in the rendering engine, essentially too much repainting and rendering stalls, and too little GPU accelerated animation paths.

Javascript is in a very good state these days in terms of cross browser compatibility, and while CSS support has converged between browsers in terms of correctness, CSS support has not converged on performance between browsers. Safari, Chrome Firefox, and IE have wildly different animation performance hazards on the same markup and debugging this often isn't trivial, for example, finding out that the GPU is stalling on texture uploads deep inside of the render loop.

One bright point, is that apps like Inbox are forcing these issues to the front, as is libraries like Polymer/Material Design. As the issues are raised and fixed, jank free rendering on mobile web platforms improves, hopefully reducing the need for native apps.

Glad to hear that these improvements are being addressed, but if the problem was animations why not opt-out of those when performance is an issue?

Inbox is a showcase for Material design, which makes heavy use of animations. If you don't need the animations, you can just use the gmail.com page anyway.

Why is poor performance in one browser a reason to completely drop support for that browser? If it works correctly albeit slowly, why not support it anyway? Then the slow experience is motivation for the browser vendor to improve it as well.

Because users aren't going to blame the browser vendor for the poor experience?

Users won't get to use the site at all.

You can spoof the user agent in Firefox and see for yourself. It's _really bad_, bordering on completely unusable (at least, it was at launch). Inbox uses a lot of animation, and having that animation run at a couple frames per second makes an exceptionally poor user experience.

If I worked on Inbox, I wouldn't feel comfortable releasing anything like that on Firefox either, even if it was gated with a disclaimer. It wouldn't reflect well on Google or Mozilla.

That would require them to file bugs against the browser. In the case of the sparse array issue, nobody had filed anything until a Mozillian read about the issue here on HN. It was fixed in Nightly the same day.

Extremely interesting! Would love to see blog posts on debugging GPU stalling during browser render loops, but I suppose you are all probably too busy actually doing that really hard stuff to be writing blog posts about it!

It's not available on other Blink browsers, either. (Do other browsers use V8? My google-fu is weak!)

It works fine on my Firefox when changing the user agent.

for me it keeps spinning on their own loading widget (the main UI shows up, but the loading bubble at lower left never goes away), and I cannot open any of the emails. This is with firefox 36 beta 6.

Edit: using https://addons.mozilla.org/en-US/firefox/addon/enable-google... which works much better

Reply on news.ycombinator.com