Yea, I call complete B.S. Look how well the LinkedIn app performs. It's not as good as it could have been if it was 100% native, but it's no where near the bag of rocks the FB app was. I work on native iOS and HTML5 apps every day, HTML5 isn't close to native, but you can still get it to perform damn well enough. FB had no excuse for that shit they released, they should have held onto Joe Hewitt to fix it. (I don't know what the inside story was though).
I read the story on FB newsroom. I see that site is built on OLD asp.net webforms. Not even asp.net MVC. If their devs are constantly using the oldest of tech to create their site, it's no wonder their shit performs so badly.
Now I have no idea or backstory to why they choose these routes, they most probably simply didn't have any developers with enough experience or skill set to use newer better performing tech (I hear it's hard to find good developers).
The press room site is not their main site, and I believe is not even run by Facebook. Many companies outsource their investor relations and press websites. None of Facebook's primary site is running ASP or anything Windows-related (they use PHP). It's pretty safe to say that none of the people developing Facebook's main site, services and mobile apps are behind the press site...
Facebook develops their main site in PHP. They even wrote their own PHP compiler[1], and various other pieces of infrastructure (e.g. [2]). I'm not a huge fan of PHP, but compared to other PHP projects I've worked on their infrastructure looks nice and modern.
I read a venturebeat article on the LinkedIn app, seems like they used some Node.js, a bunch of work arounds and A LOT of domain expertise to get it to work as well as it does. I personally found the article interesting as I'm trying to figure out native vs. HTML5. seems like, barring incredible expertise about the quirks of html/js, native is the way to go.
I don't know enough about their app to give a detailed response, but it seems like the optimizations they performed could have just as well been applied to their HTML5 version. WebWorkers, for example, are available on iOS.
It could be that they could never get true native speed without writing it natively. However, in my experience their HTML version was so awful that I suspect a lot of it was from bad decisions on how to use HTML5. That may be the problem though: that it takes deep knowledge to know how to leverage it correctly and speedily.
If a company has the resources to support native development, I think there's no reason to stick with an hybrid HTML5 app. It's well-known that (because of security reasons) JavaScript is slow in a UIWebView compared to a real website, see: http://blog.mobtest.com/2012/05/heres-why-the-facebook-ios-a...
I think that staying HTML 5 is a mistake. As the needs of your app expand, there will be a greater and greater need to use native API's. The longer you develop in HTML 5 the more code you will have to port when you finally do decide to transition to native. You're better off minimizing your pain and transition to native early when there is less code to port.
I think that Facebook has enough resources that they should go native. But I also don't think that HTML5 is as bad as Facebook has made it look (having made an HTML5-native hybrid app myself), and I think it's still a valid choice for smaller outfits.
That said, my greater concern isn't performance on HTML5, it's interface. iOS, Android and (particularly) Windows Phone have very defined UI metaphors and design styles that vary a lot- if you have to replicate all of them then it removes a great deal of the benefit of a cross-platform app.
The answer may be, weirdly, in C#, using MonoTouch and MonoDroid. You'll always have to tailor UI to each OS, but having an entirely consistent backend to that UI is an attractive option. I just haven't managed to convince myself to drop the cash on a license yet, though.
Who here thinks that Facebook should have stayed with HTML 5?