The problem with apps developed in HTML5 that is not stressed enough IMHO is that the iOS API is good, while the HTML5 API to do a lot of advanced stuff is still limited. In short to develop a native application does NOT take more time than developing one in HTML5, at least for iOS devices. I can tell this first-hand as I used to advice an iOS/Android software company in the past, composed mainly of friends of mine, and in three years of projects the native approach always won: better responsiveness, more access to lower level primitives when needed, native look and feel, easy of development.
And I'm talking about a small startup. To take the HTML5 approach to develop a mobile application for a very large company is simply silly IMHO, and Facebook CEO is right that this was an huge error in their side.
> develop a native application does NOT take more time than developing one in HTML5
Unless you already have an HTML5 desktop app. In which case, the only thing you're doing is modifying the UI for touch-based input and a smaller screen ... which doesn't take much time at all.
Facebook's problem was that their app sucked. It didn't suck because it was HTML5. It sucked because it was done poorly.
For an HTML5 desktop app to become a good HTML5 mobile app usually the changes are so big that you end anyway with a different set of code generating the output for the two "sides".
It does not matter that's HTML+CSS+JS both sides, the device, the interaction, the screen real estate, and the user behaviour when seeing this content in mobility is different.
Actually the risk is that trying to make an HTML5 desktop app also good for mobile is that you overlook a lot of good interactions that are not natural consequences if the starting point is the desktop app.
> For an HTML5 desktop app to become a good HTML5 mobile app usually the changes are so big that you end anyway with a different set of code generating the output for the two "sides".
I'm actually working on this right now.
HTML and CSS served to both desktop and mobile are identical. HTML is just headers and an empty body tag. CSS has shared code and @media specific to each interface.
Every visual element is built through JavaScript/DOM.
Javascript is split into two sections/folders. Logic and visual. Mobile and Desktop share the logic javascript, but not the visual.
Everything you can do on the desktop, you can do on mobile. The only differences are in how the visual elements are presented.
Having been down this path before, I predict you will find that the "last 10%" of those small, annoying things that don't quite work like native mobile apps in HTML5 will take the same amount of time to fix as developing the rest of the app.
If you don't think this is the case then either you aren't far enough along to hit the problems or your app doesn't make heavy use of hardware (which - given that it is also a desktop app - it sounds like it probably doesn't). In the second case then using HTML5 makes good sense.
> The only differences are in how the visual elements are
> presented.
If you don't care about performance, then yes. Everything that affect desktop web performance for the worse (number of requests, latency, lame caching policy) will bite you hundred times more on mobile.
IMHO is that the iOS API is good, while the HTML5 API to do a lot of advanced stuff is still limited.
Can you give a few examples? HTML5, CSS and JavaScript support many features on mobile devices these days: geolocation, access to camera/microphone, orientation detection...
In short to develop a native application does NOT take more time than developing one in HTML5, at least for iOS devices.
But then if you want to support Android, you need another native app. And then another one again if you want to support, say, the new Windows phones. In contrast, a web app that is mobile friendly can be reasonably portable across platforms with a single codebase.
Moreover, even if you can develop your app within the same time frame, you still have the App Store approvals process to pass, and you have Apple cutting significantly into your revenues if you're charging.
Obviously these arguments probably don't apply to Facebook, but you said you were talking about a small startup, where everything above is definitely relevant.
That's what I saw observing the guys at Kiurma in the latest three years:
1) Most stuff is developed for Android and iOS, and all the rest is served via a CSS that is made mobile-friendly. So developing a native app for iOS + Android you cover 95% of the important target in the best way, and all the rest can stil access your services. So actually, for now, it's just two platforms and not N at least.
2) If you do the iOS application first, instead of trying to make the Android/iOS in parallel, then the Android app takes like 30% of the time of the first at max. You end just copying the iOS app just "translating it" into Java+Android SDK, so the time, in my experience is not 100% + 100%.
3) Anyway once you want to create a native look & feel in different devices, and want to make sure that the javascript, interaction, ..., all look the same across devices, even HTML5 is not exactly cut & paste.
4) It's true that apple takes 30%, but the possibilities of customers just hitting "purchase" button with a 0.99$ price tag or alike are a lot bigger compared to creating your way of making them paying. So IMHO the 30% cut often is justified by the advantages in the "processing" of the payment and in a raise in percentage of people motivated to buy because it's simply easier for them.
5) It's true that you can do stuff like playing videos, capturing images, or audio, or location. But trust me, if you try to do Instagram using this API the result is NOT the same. Doing stuff in HTML5 is often too slow, or you have too little control about how stuff is presented (see HTML5 playing of videos on iOS), or you can't use gestures well enough, or stuff are not working ok on Android or vice versa. Tons of problems.
6) A big pro of native is background. The iOS / Android location service that can awake your app when there is a significant change of position is extremely useful in a lot of social-alike apps.
So even with the small startup IMHO the quality you end with, responsiveness, and often also easy of development, more than justify to go native for everything but the most "just show some content" of the apps.
But after all, even Facebook should classify as a "most show a feed of stuff" app, that is one of the naturally prone to work in a decent way with HTML5, but still...
And I'm talking about a small startup. To take the HTML5 approach to develop a mobile application for a very large company is simply silly IMHO, and Facebook CEO is right that this was an huge error in their side.