Yes, actually, I know exactly why Facebook's moved away from it: the beginnings of their HTML5 mobile strategy actually pre-dated the original iPhone, and as such they were using a strategy that didn't really make sense in the post iPhone world. Namely, the app was pulling down the mobile version of their website from the server on every request, which as you might imagine meant things were generally pretty sluggish. So it was really no different than just hitting the mobile version of Facebook with mobile Safari. Contrast this to using a javascript app that runs off the phone's file system and just makes requests to the server for JSON data, caching that data in localStorage along the way (which is what we do). That strategy is really no different than what fully-native apps do except that you're presenting and managing the data in a webView rather than a UITableView. It's much more performant with the benefit of using HTML/CSS for (cross-platform) layouts.

LinkedIn's move away from HTML5 I can't explain as well, although they do mention issues with memory management and a lack of good development tools out there. We haven't run into any issues like that but every use case is different. I do know that LinkedIn, instead of using Phonegap, wrote their own native bridge using websockets and a mini web server that would run natively that they themselves admitted wasn't the best approach. I think there's a lot of pressure, especially in large companies, to move to fully native apps these days because of all the negative press about HTML5, so instead of doubling down engineering efforts to solve problems that arise teams are much more likely to take the nuclear option and just rewrite everything in native code (twice!).

So no, it's not that they have a "grudge against HTML or something", it's that they ran into limitations due to specific circumstances unique to their products and strategies and took the safe path of going fully native to guarantee optimal performance at the cost of productivity (IMHO). If there was no native app option, they would figure out clever solutions to their problems from which the entire web community would benefit.

Thanks. How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness.

My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either. Native is more predictable. Your experience is valuable in that it proves the existence of a solution. Would you say your team is extraordinary in its capacity to wrangle with HTML, or is something like this available to your average YC startup, or to most startups out there?

> How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness.

We've had no issues with it so far and I heard the same criticisms you did. If you make sure not to store too much stuff in localStorage (there is a limit for UIWebViews) you should be fine.

> My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either

I get that, but it does overestimate the capabilities and resources of FB and LinkedIn. In the end, they are just developers like any other developers solving the same problems everyone else is, and simply throwing more money at the problem doesn't usually fix things. Keep in mind that there's a lot more pressure on FB and LinkedIn to deliver perfection so they are going to be less likely to "stick it out".

> Native is more predictable.

I agree, and there are lots of other benefits to native as well. They must be weighed against the detriments: having to write the same app multiple times for multiple platforms, having to play by Apple's rules, not being able to update apps for customers immediately (that's a huge problem IMO), working with painful layout tools, etc. As always, it's important to weight the pros and cons before choosing a strategy.

> Would you say your team is extraordinary in its capacity to wrangle with HTML, or is something like this available to your average YC startup, or to most startups out there?

I assure you we are not extraordinary. Anybody with a very basic level of native programming experience and who is competent with HTML5/CSS3 and the latest javascript frameworks (backbone, ember, angular, knockout, etc) can replicate what we did. I think the reason it seems extraordinary is because you only ever see articles about big, trendy companies ditching HTML5. "Small unknown team builds great HTML5 mobile app" just doesn't have the same punch. I also believe there is a bit of religious war going on between web developers and native developers so there's always a frenzy whenever there's a drop or two of blood in the water. Ignore all that crap and just choose the solution that suits both your app's requirements and your skills best.

> using websockets and a mini web server

Whoa! That sounds super convoluted.