HTML5 is dead. Long live HTML5!
Before you take Mark Zuckerberg's HTML5-bashing as evidence that Web apps are dead, remember that Facebook's problems are not everyone's problems. And the company still likes Web apps in some circumstances.
HTML5 fans got a very large splash of very cold water in their faces yesterday.
Facebook has been a big fan of building mobile apps using HTML5 and related Web standards, but no less than founder and Chief Executive Mark Zuckerberg called Facebook's HTML5 app "
Those are powerfully damning words, and many developers will likely take them to heart given Facebook's cred in the programming world.
But there are subtleties here -- not an easy thing for those who see the world in black and white to grasp, to be sure, but real nonetheless. Zuckerberg himself offered a huge pro-HTML5 caveat in the middle of his statement.
Here's a fuller version of his words from the TechCrunch Disrupt conference:
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 built this internal framework that we called FaceWeb, which was basically this idea that we could take the infrastructure that we built out for pushing code every day, not having to submit to an app store, to build Web code on the Web stack that we have, and that we could translate that into mobile development. We just never were able to get the quality we wanted...
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. The iOS app, I think, is in good shape, and the Android one will hopefully be soon.
Zuckerberg is no engineering lightweight, and discussing the mistake publicly must have been painful. But you can bet that betting so strongly on Web apps then reversing course was even more painful.
But there's important context to Facebook's decisions that weigh into the discussion here. First off, the company was born of the Web, with a browser-based interface since its inception.
That's the kind of foundation that's very hard to shake. Aside from the issues of cultural momentum and in-house expertise, which often lead companies to continue with the existing programming approach, there's a powerfully addictive attribute of programming on the Web: distribution.
When you program a Web site, users get the latest version of your app when they log on. Making a major change? Push it onto the Web server and away it goes. Need to fix a bug or close a security vulnerability? The next time a person uses your site, it's fixed.
That leads to that heady drug of programming, velocity. Google, with its release-early-and-iterate-often philosophy, has it too. No longer are you subject to onerous annual or quarterly or monthly release cycles. No longer do you have to wait for Apple's App Store editors to give your app the thumbs up. No longer do you have to worry that you'll have to support half your user base using an 11-year-old operating system the way Microsoft programmers must with Windows XP.
So it was natural for Facebook to opt for a Web app -- much more natural than it would be for, say, somebody writing a casual game.
The native iOS app is more responsive, and Zuckerberg said usage rates with it are much better. That's great, but with it and a native Android app under way, people will be reaching for the update button in their app stores a lot more often.
Another big factor is Facebook's reach. With hundreds of millions of users, the company must reckon with innumerable computing devices. Browsers are a natural way to reach all of them -- indeed, Facebook touted its Web-app approach with the old Java tagline: "write once, run anywhere."
The Web's breadth is unbeatable when it comes to cross-platform programming, and that doesn't look likely to change any time soon. iOS continues to gain in importance, as does Android, but Windows is hardly fading away. Programmers today must reckon with more operating-system diversity than ever, and browsers give them a way to smooth over the differences.
The problems -- and promise -- of Web apps
But nothing is ever so simple, of course. Browsers span many devices, but there are innumerable major and minor differences among them. The browsers on your PC, smartphone, and TV come with wildly divergent abilities.
For that reason,with a mobile-browser compatibility test called Ringmark.
"There's rampant technology fragmentation across mobile browsers, so developers don't know which part of HTML5 they can use," said then-Chief Technology Officer Bret Taylor in a February speech. ( to join a startup.) And although Web technologies pushed by Mozilla, Google, and others are gradually adding the programming interfaces that native apps get -- notifications, for example -- they generally lag.
So yes, Web apps have problems.
But they still have that reach, velocity, and cross-platform advantage. Web apps may not be the best pick for a first-person shooter or a company the size of Facebook, but there are plenty of mobile apps that aren't as performance-sensitive or that act as a frame to pull in content hosted on a Web site. And there are plenty of developers steeped in Web technologies who'll be able to get a start on mobile because of browser programming techniques.
And the Web continues to mature. Just yesterday, the Internet Engineering Task Force, a compression technology that is slated to power a new . -- but WebRTC would let it build voice calls and videoconferencing straight out of off-the-shelf Web standards. It's already got plenty of members connected to each other.
So don't dismiss Web apps as too feeble. They may not be the right answer for everybody, but even Facebook will continue to rely on them.