4 ms·
Isn't this still fundamentally a problematic approach, though? Yes, being Chrome-only at launch was a bad idea (and the predictable response was that tweet and
by azakai 12y ago
Isn't this still fundamentally a problematic approach, though? Yes, being Chrome-only at launch was a bad idea (and the predictable response was that tweet and its thousands of retweets), but even if it were "Chrome + a notice about Firefox soon", and some time later it does run on Chrome and Firefox, that still leaves out all the other browsers!
I understand that you want 60fps flawless performance for your new product. But if you need to work in close cooperation with a browser vendor in order to enable that, then either you work closely with all the browser vendors - which might be possible in theory, but unlikely in practice (you don't have enough resources/interest, they don't have enough resources/interest) - or your product will not run on all browsers.
I honestly think this approach is not a good one. Alternatives which are at least less bad are
1. Let everyone run the app. Yes, some browsers will not hit 60fps. That's already true - even if they run it on your choice of browser, it may be on a slow machine. In this approach, some browsers will do less well, and one may be tempted to write something to the effect of "best experienced in X" but that's just getting back to that tweet (which while snarky, had a valid point). The best you can do here is proactively test on other browsers and file perf bugs on them. Reduced testcases can be filed before your product is public.
or
2. Rely less on browser optimizations. As your linked comment correctly mentions, how browsers do layout, create layers, upload them to the GPU, etc. differs between browsers. But the web is no longer limited to that. You can use WebGL - now present even in modern versions of IE and Safari, which means in all browsers - which gives you explicit control of how to create layers, when to upload to the GPU, etc. Of course, this is no guarantee of 60fps performance everywhere (nothing is, there are slow GPUs, etc.), but it has a far higher chance of running at a predictable and high frame rate than letting the browser's layout engine guess for you.
- cromwellian 12y agoIf 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.
- azakai 12y agoI get what you're saying about i18n in the alternate approach. It's harder to do those things there. But isn't "designed for Chrome and Firefox" just a marginally better thing than "designed for Chrome"? It's still tailor-made for specific browsers, just 2 instead of 1. That's very un-"webby".