Mark Zuckerberg made waves when he called Facebook's early reliance on HTML5 the company's "biggest mistake." Here are some details about what he actually meant.
In company with the rest of the industry, we've spent a good deal of time discussing native vs. Web application development; for example see here, here, and here. There are some things the Web simply can't do yet -- the APIs proposed for standardization have not gelled sufficiently. And there are other things for which the performance of Web apps isn't good enough or predictable enough, yet. For both of these situations, the gap will narrow over time.
Let's get on the record the complete quote from Zuckerberg (according to Facebook engineer Tobie Langel), not just the "biggest mistake" sound byte that much of the media quickly echoed:
When I'm introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native... because it just wasn't there. And it's not that HTML5 is bad. I'm actually, on long-term, really excited about it. One of the things that's interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.
It sounds as if Facebook bought into HTML5 hype a couple of years too soon, but has not given up on the ultimate promise of a consistently performing, fully cross-platform solution emerging from the standards process -- eventually.
A few days after Zuckerberg made his remarks, Tobie Langel (the Facebook engineer) posted a list of the factors that caused problems for Facebook on the Web application side of its development efforts.
The problems Langel outlines fall into three main areas: tooling and developer APIs, scrolling performance, and access to the GPU.
The Facebook complaint about tooling is not unique to their particular app; anyone developing a resource-intensive app in HTML might have similar issues. The problem as Langel sees it is that the debugging tools in mobile browsers don't provide enough visibility into what is happening with memory in particular. How big is the heap, how many of some particular object have been created in memory, how close is the app coming to exhausting some resource or other? When a mobile app crashes because of resource exhaustion, it's often difficult or impossible to find out what ran out. Langel notes that an API to a device's memory resource would be a fine solution, but it could contribute to privacy concerns by its assistance to device fingerprinting.
The nature of Facebook's app contributes to the difficulties it encounters with scrolling performance across mobile devices. Facebook's newsfeed and Timeline in particular experience slow and inconsistent performance because they implement an "infinite scrolling" model in which content is pre-fetched and appended as the user reaches its location. The number of objects in memory, including graphics, can grow quite large. Different browsers make different tradeoffs in these extreme situations, resulting in inconsistent frame-rates, exhaustion of GPU buffers, lagging of UI threads, etc.
Langel notes that GPUs tend to be black boxes to the app developer (and that the GPU makers, for their own reasons, like it that way). In an app like Facebook, with the size of the data being handled so far outstripping the size of GPU buffers, Langel believes that it is unlikely to be optimal to leave GPU management to the browser.
Some of these issues represent growing pains of a not yet fully mature development platform, and some the detailed consequences of standards being implemented with different emphases by different companies and organizations. These issues are being introduced into various W3C working groups by Facebook and others. Over time we'll see the Web platform narrowing the performance and capability gap with native facilities.