5 ms·

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 cl

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.

cromwellian 12y ago
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. :)
- Touche 12y ago
  What are you doing that makes performance that bad? It sounds like GWT is generating bad code...
  - cromwellian 12y ago
    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.
    - Touche 12y ago
      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?
      - sp332 12y ago
        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.
    - AshleysBrain 12y ago
      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.
      - JshWright 12y ago
        Because users aren't going to blame the browser vendor for the poor experience?
        Touche 12y ago
        Users won't get to use the site at all.
      - jamesgeck0 12y ago
        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.
      - dblohm7 12y ago
sp332 12y ago
It's not available on other Blink browsers, either. (Do other browsers use V8? My google-fu is weak!)
timo777 12y ago
It works fine on my Firefox when changing the user agent.
- khc 12y ago
  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-inbox/ https://addons.mozilla.org/en-US/firefox/addon/enable-google... which works much better

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.

cromwellian 12y ago

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. :)

Touche 12y ago
What are you doing that makes performance that bad? It sounds like GWT is generating bad code...
- cromwellian 12y ago
  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.
  - Touche 12y ago
    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?
    - sp332 12y ago
      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.
  - AshleysBrain 12y ago
    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.
    - JshWright 12y ago
      Because users aren't going to blame the browser vendor for the poor experience?
      - Touche 12y ago
        Users won't get to use the site at all.
    - jamesgeck0 12y ago
      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.
    - dblohm7 12y ago

sp332 12y ago

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

timo777 12y ago

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

khc 12y ago
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-inbox/ https://addons.mozilla.org/en-US/firefox/addon/enable-google... which works much better