HTML5 by jgn on Thursday, February 3, 2011 in Technology

I was noting to an entrepreneur friend Facebook's recent decision to deliver their mobile apps via HTML5 ( http://blogs.wsj.com/venturecapital/2011/01/25/with-plenty-of-cash-facebook-targets-growing-mobile-market/):

“Mobile is the primary focus for our platform this year,” [CTO Bret Taylor] said, noting that 200 million people are currently accessing Facebook on mobile devices. Not only is that group twice as active as their desktop counterparts, that user segment is growing faster than any other, he said.

That growth, combined with what Taylor called the “inherent engineering challenge” of mobile today, represents a major headache for him and the tech team he leads at Facebook.

Namely, whenever they update a feature on the site, they have to do seven versions, so it can run on the iPhone, Android and other platforms now in use.

“HTML5 is the future platform,” he said. “That’s where we’re putting a huge amount of our resources.”

By developing for the browser, they don't have to create separate versions for iOS, Android, Symbian, Blackberry, etc.

My friend said: But the user experience is unpleasant where you have to bookmark a link and save it to the desktop (so that it will look like a "normal" app). And he noted that since connectivity is so spotty in North America (and, I would add, in certain buildings and on the subway, etc.), web delivery is problematic. Finally, he said: "Yes, it takes more work to make an app, and to maintain it. But wouldn't you rather have more usage?"

To which I said:

I think most of your points have solid rebuttals. I should probably go through them, because I have been asked by a number of developers and entrepreneurs whether they should be developing native or HTML5 apps . . .

Delivering an app -- any app -- on these mobile devices already requires connectivity. So whether it's the app store or via HTTP, you still need a connection. Indeed, the Apple App Store requires a wifi connection (same for Android? I can't remember; I sure hope not). You can't install or update an app on iOS via 3G. A web-based app can be delivered by 3G or wifi. So I think connectivity as a differentiator for delivery per se is a red herring.
The whole "bookmark to desktop" mechanism is something that could be overcome (by Apple). It's a detail that is probably there just to make the experience harder so developers and consumers will favor the app store which makes Apple more money. Plus, if Facebook goes HTML5, that may teach everyone how to do it anyway. Meanwhile, my experience with the Apple App Store has been that it's buggy and peculiar. Just today I was asked to sign off on the latest licensing/terms and it was a bizarre back-asswards experience.
You can cache an HTML5 app so that successive runs don't require the network to start up. I don't do it (yet) for a product I'm working on for a lot of reasons. HTML5 provides for on-board databases, etc., so access to the network while running can be mitigated (i.e., data can be downloaded for later offline use). There are HTML5 apps that people think are native apps -- the best are probably the ones Google has created.
What are these apps we're using that don't require connectivity? I was looking over my apps and I could find only one that doesn't require connectivity while it is running (a game). It could probably be implemented in HTML5. I know this particular company has a web-based version of the game already; I'm sure they did it as an app so as to sell it through the app store and make some money that way.
I was just using the new much-ballyhooed "Daily" app, and was shocked at how terrible its performance is. Why? Because it tries to use a lot of UI gewgaws that it would probably skip were it delivered in HTML5. It's appalling. It has a rotating kiosk for news that is just plain slow and jumpy. Another really interesting user experience case is the iPad NY Times app. Have you used it? There isn't as much news as the web site! I was kind of shocked. It's somewhat "curated," which is a weird approach to take for the paper of record. Why? I wish I knew.

Just speaking for myself, the browser experience of the NY Times on the iPad is much better than the app. And the Times has browser-based apps that are awesome (example: http://www.nytimes.com/skimmer/ -- not sure why the Times hasn't flogged this more), but don't yet work very well on the iPad. If they did . . .

A really interesting case is the New Yorker. This is currently being delivered whereby each separate issue comes down as a separate app. I would bet that the motivation is connectivity (besides greed -- each issue is $5), so the whole content of each issue is downloaded. But no one's buying it, either economically or conceptually. 6. If I can get more usage by writing one app that can be delivered to Apple, Android, Blackberry, Symbian, etc., etc., don't I get more users that way? 7. Then there's the question of getting access to the "bare metal" for speed or services. Android apps are written in Java, so you don't get that anyway (well, it's awesome, but it's still not right down there at the metal). There are apps on the Apple mobile infrastructure that are hard to imagine without being written in Objective C, so I'll grant that there's a class of applications that would be hard to do in HTML5.

What am I missing? I think mainly, and obviously, the economic model of the app store. It's great to sell your product via Apple or Android's marketplace. But if your app is free, as is Facebook's, I'm just not seeing it. Games, audio and video apps: These I can see the need for native delivery and the money mechanism of the app store. Indeed, the top-downloaded and top-grossing paid apps on the app store are all games or audio:

But for business-oriented apps . . . I'm just not seeing much of a downside to HTML5.

Thoughts?