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.
Stephen Shanklandprincipal writer
Stephen Shankland has been a reporter at CNET since 1998 and writes about processors, digital photography, AI, quantum computing, computer science, materials science, supercomputers, drones, browsers, 3D printing, USB, and new computing technology in general. He has a soft spot in his heart for standards groups and I/O interfaces. His first big scoop was about radioactive cat poop.
Expertiseprocessors, semiconductors, web browsers, quantum computing, supercomputers, AI, 3D printing, drones, computer science, physics, programming, materials science, USB, UWB, Android, digital photography, scienceCredentials
I've been covering the technology industry for 24 years and was a science writer for five years before that. I've got deep expertise in microprocessors, digital photography, computer hardware and software, internet standards, web technology, and other dee
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.
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.
"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. (Taylor has since left Facebook 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.