If we had the resources and didn't have constraints to co-launch with Android Lollipop and iOS, making it work on all the browsers out launch may have been feasible. We had bugs filed for most of the issues in our internal tracker, but we ran out of time before launch.

This is a problem at big companies like Google and probably Apple, is that we time major sets of released functionality for 'big impact' launches like Google I/O, or other media events, and the poor engineers are left working late into the night to meet the deadlines.

As for just rendering everything with WebGL or Canvas, we could do that (Google Sheets uses Canvas), but it kind of rubs me the wrong way, it doesn't feel "webby". You end up reimplementing tons of stuff: Bidi/I18N text handling, A11Y, system behaviors like text selection, clipboard, it just seems like you're making your own Flash runtime in JS, an alien hybrid that displaces the entire browser engine.

I hope apps like Inbox, and the new focus on mobile web performance by both Google and Mozilla can fix many of these layout/rasterization/composite hazards, either at the spec level (e.g. will-change), or at the implementation level, so much like there is a 'war' on JS performance, there can be a 'war' on layout and paint performance.

Long term, if we want the web to succeed and not be destroyed by mobile native apps, we need it to work -- as the web --, and not as simply opaque WebGL + JS, that's basically just a native app model with a different VM.