HTML5 isn't Facebook's 'biggest mistake'
Zuckerberg's excuse risks movement's set back
Open ... and Shut Everybody makes mistakes, but if you're Facebook chief executive Mark Zuckerberg, mistakes can shave 50 per cent off your market valuation in a matter of weeks. Happily, admitting Zuckerberg-sized mistakes apparently is also worth a 7.9 per cent bounce.
Zuckerberg's biggest mistake, as he described in an interview at the Disrupt conference, was "betting too much on HTML5 as opposed to native" app development. For a man who two years ago said he's made "any mistake you can think of" but affirmed "if you're building a product that people love, you can [afford to] make a lot of mistakes," singling out HTML5 seems weak. Especially in light of the IPO debacle.
But then, the problem doesn't seem to be HTML5, per se, but rather Facebook's use of it.
Zuckerberg hints at this in his conference remarks:
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.
It's not that HTML5 is bad. I'm actually, 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... We just never were able to get the quality we wanted [from the HTML5 apps we were building]...
We burned two years. That's really painful. Probably we will look back saying that is one of the biggest mistakes if not the biggest strategic mistake that we made. But we're coming out of that now.
Maybe, but there's a lot of blame to throw around, and HTML5 is only one target. Instead of pointing his finger at HTML5, Zuckerberg might be better served by looking inside his company to see how it was deployed. Facebook's approach to HTML5 has been hobbled by politics and a lack of expertise, both in HTML5 and in mobile. Zuckerberg is correct that today's HTML5 tools aren't perfect, but in this case the problem may lie more with the craftsman than with the tools.
As a company that grew up on the web, Facebook had every incentive to get HTML5 right. Long before Facebook released its HTML5 app, the company had been experimenting with the technology, with an on-again-off-again relationship to HTML5 led by Joe Hewitt and then Bret Taylor after Hewitt quit. If Zuckerberg needed a warning that his engineers were struggling to be productive with HTML5, Hewitt gave him one, arguing that the pace of web innovation had slowed relative to native app development, perhaps forever.
Still, Hewitt's hybrid HTML5/native app was quite good. The problem was that there wasn't anyone who could effectively improve upon it once he left, according to Mozilla chief technology officer and former Hewitt colleague Brendan Eich. And so Facebook went shopping, pulling in my former company, Strobe, as well as other talented developers.
Unfortunately, it was too late to save Facebook's HTML5 app. And the reason, apparently, was politics. Or, as mobile HTML5 guru and Tilde co-founder Yehuda Katz terms it, execution:
Katz's argument is bolstered by a source familiar with Facebook's mobile development efforts, who walked me through the history of Facebook's mobile app development. Apparently, the server team and the mobile team were at loggerheads as to how to deliver content to mobile. Initially the mobile team had a solid hybrid HTML5/native approach in mind, and asked for a JSON feed so that they could do things like cache content locally and render instantly in the event of a lapsed connection, high latency. They were told, however, that they could only get HTML, the same as the server team delivered to the desktop app.
Ironically, as a way to gain leverage, the mobile team then moved to a native app and insisted on getting the JSON feed as it no longer had the ability to render HTML. Even more ironically, in the process Facebook developed a solid JSON API and is well-positioned to switch its app back to HTML5.
Given the above, perhaps Facebook's takeaway should have been "there is a rational way to architect our HTML5 apps," rather than "native always beats HTML5."
There are certainly those at Facebook who will disagree with this characterization of the internal debate. As one Facebook contact (who may be the world's closest approximation to Super Mario in appearance) told me, it's not at all clear that client-side rendering via JSON would have fixed Facebook's HTML5 issues. Facebook tried to do this, to no avail, leading him to echo Zuckerberg's sentiment that for Facebook, anyway, HTML5 "just wasn't there".
Maybe, maybe not. But it seems clear that Facebook's efforts with HTML5 weren't as consistent as they might have been. And it's equally clear, from Facebook's acquisition of Instagram and other mobile-oriented companies like Spool, that the company has lacked a deep bench in mobile expertise, expertise that could have engineered a better HTML5 approach.
But it may precisely be the level of expertise required to make HTML5 apps "sing" that is a key reason the company is shifting more of its efforts to native app development. As one Facebook engineering manager shared with me:
It's fair to say that part of being an effective platform is not only that you're technically capable of doing something, but it must also be easy and scalable enough that 'mere mortal' engineering teams can achieve good results [with it]. It's clear that HTML5 is hard enough to get good results that you end up losing the supposed benefits of moving fast.
Right now Facebook moves fastest by writing native code. This isn't to say HTML5 won't ever be able to live up to the hype, but just that at this point Moore's Law and the web engines still have some ways to go. So we made a pragmatic decision. Eventually if HTML5 lets us move faster you could expect to see us move back to it. We are going to use whatever tech stack lets us do high-quality work at a fast pace.
Even so, Facebook's experience may not mean very much for other developers looking to build mobile apps. Facebook, after all, operates at a scale most developers will never see. Its needs are very different from those of most developers, as Cnet's Stephen Shankland rightly argues. For many developers, building an HTML5 app is not a second-choice option, but actually should be their preferred option, a thought alluded to by Mozilla's Eich:
Companies like Facebook can afford to do a native [app], especially on iOS. But for the long tail, developers will generally do the web and often be content there. If the web can be evolved to include the missing APIs and have better performance, [developers] won't need to go beyond the web.
Organisations like Mozilla and even Intel are actively working to improve HTML5 performance. An Intel executive recently admitted that HTML5 has been overhyped while simultaneously pledging to help improve it so that it can live up to the hype. Facebook, too, remains committed to HTML5, at least for some of its apps.
In sum, Zuckerberg's comments sounded like a criticism of HTML5, but may actually have been a dual indictment of the technology and his team's ability to deploy it. It would be unfortunate if his seeming deprecation of HTML5 ends up setting back a movement that could do more to help Facebook chart its own destiny than anything else, rather than remain yet another app/pawn on Apple's platform. That would be another big mistake to add to his list. ®
Matt Asay is senior vice president of business development at Nodeable, offering systems management for managing and analysing cloud-based data. He was formerly SVP of biz dev at HTML5 start-up Strobe and chief operating officer of Ubuntu commercial operation Canonical. With more than a decade spent in open source, Asay served as Alfresco's general manager for the Americas and vice president of business development, and he helped put Novell on its open source track. Asay is an emeritus board member of the Open Source Initiative (OSI). His column, Open...and Shut, appears three times a week on The Register.
Sponsored: Optimizing the hybrid cloud