Facebook used HTML5 for a variety of political and technical reasons.

On iOS, using HTML5 decoupled deployment of functional changes from the App Store approval process. They could add a new feature on the servers and have it available on phones immediately. Certain parts of the new app still use HTML to allow new features without updating the whole app.

On Android, HTML5 let them support a large number of phones with fewer special cases to work around old versions of the OS and phone-specific bugs.

Except that, once you're done developing a hybrid app, you now have a giant chunk of reusable code. Facebook simultaneously supports several different platforms (normal website, mobile website, iOS app, Android app, Windows Phone app, Blackberry app, etc). Any amount of code reuse is a huge win when you're trying to maintain feature parity in many different directions.

Oh come on, you are making it sound as if it would be a massive investment for Facebook to develop native apps for multiple platforms.

If I can build a Facebook client that covers the most important features within 3 months (at 2 evenings per week after work) then I'd bet that a company like Facebook (with hundreds of developers that are much better than I am) could invest the needed resources (maybe 3-4 developers per platform) to create a truely amazing native experience.

I'd even argue that it is not an option for anyone in their position to even consider going HTML5 just to reuse some code. That would be just the wrong place to save a few bucks for them, considering that they need to make a transition to mobile pretty soon and failing to do so would be an open invitation for competitors to come and basically kill them.

Additionally I'd like to add that I am not convinced that is even possible (or if so many times harder) to create a content rich application like Facebook with webviews wrapped in native code that feels as fluid and responsive as a full native app. I have tried this in the beginning with my Facebook client (app link: https://play.google.com/store/apps/details?id=com.flipster) and failed miserably before stopping this webview nonsense, and so did the Facebook developers.

Agreed.

On the scale of Facebook's resources, building well-functioning apps just isn't a hard problem. Not saying it's not hard, just saying it's not hard on the scale of Facebook's resources.

Creating a functional and performant HTML5 app shouldn't have been hard at their scale either. So either it's actually impossible to do better than what they put out (which I find hard to believe -- is it really that much more complex than the HTML5-based LinkedIn app?) or there's some other reason.

I just can tell you what my experience is. I was unable to do it, but what you have to consider on Android is that a many customers are going to use crappy cheap phones with a weak processor, so every layer of abstraction added is going to hurt the performance a lot.

Additionally making the mobile app run smoothly on any device is just the bare minimum for what they should deliver. It's hard to not compare it against competition like the Android Google+ app, which absolutely crushes the Facebook app (I'm talking about the UI here, not about the social network itself), and that's where my sketicism comes from. Even if someone was able to deliver a WebView based app like Facebook, running smoothly on cheap devices, other competitors betting on native (like Google+) would still be in a different league.

How re-usable is it really? The bulk of the work is being done at the server in this case, and the app is mostly UI code. UI code is very platform dependant. I think that HTML5 is probably the future, particularly if things like Firefox OS take off, and it's probably fine for a MVP mobile app (possibly combined with something like PhoneGap). Currently though, native apps definitely provide a better experience, and you should probably do it if you have the resources... and this is from someone who really enjoys web dev and dislikes iOS dev.

+1 The whole reusability thing is a red herring, it's like the whole Java run anywhere thing, it might save you duplicating UI code but the apps will look crap and run like a dog.

I do not agree with your reasoning.

First of all, if going native, you'll have to put in twice the effort for targeting both Android and iOS, while an HTML5 app can be easily ported to WinPhone or even Symbian.

Will it be shittier than a native app if doing a straight port with no effort to make it seem native? Most definitely YES, but at least you've got an app to give to your customers that want to use your product. Because no matter how cool the new Facebook app is on iOS, I'm still and will continue to be an Android user.

Also, I do not agree that it's easier to develop that native app in the first place. I can easily do things in HTML5 in terms of UI that I wouldn't know were to begin with native widgets. All is fine and dandy when you're using the standard widgets, but if you want to have non-standard behavior, or to put your personal touch on the design, then all hell breaks loose, because those native widgets ARE NOT as fluid, as easy to change or as composable as a bunch of divs with CSS attached. People underestimating this point have never worked on designing interfaces in both HTML5 and native widgets.

And for the record, I hate the native app because it's slower than when using the website in my browser. But the work they did also improved the mobile website, which I find to be awesome.

     The current Facebook app, if developed by 
     competent guys, is a 3 months project by 2 people

Yeah and I'm sure that in their spare time those same 2 people could also build Twitter.