4 Reasons Facebook Dumped HTML5 and Went Native
Saturday, September 15, 2012 at 7:51AM 
Facebook made quite a splash when they released their native iOS app, not because of their app per se, but because of their conclusion that their biggest mistake was betting on HTML5, so they had to go native.
As you might imagine this was a bit like telling a Great White Shark that its bark is worse than its bite. A common refrain was Facebook simply had made a bad HTML5 site, not that HTML5 itself is bad, as plenty of other vendors have made slick well performing mobile sites.
An interesting and relevant conversation given the rising butt kickery of mobile. But we were lacking details. Now we aren't. If you were wondering just why Facebook ditched HTML5, Tobie Langel in Perf Feedback - What's slowing down Mobile Facebook, lists out the reasons:
- Tooling / Developer APIs. Most importantly, the lack of tooling to track down memory problems.
- Scrolling performance. Scrolling must be fast and smooth and full featured. It's not.
- GPU. A clunky API and black box approach make it an unreliable accelerator.
- Other. Would like better touch tracking support, smoother animations, and better caching.
Reader Comments (9)
I'll be talking about Android (on Nexus phones, currently Galaxy Nexus) and I don't know how much that translates to iOS, but...
... maybe, just maybe Facebook is blaming HTML5 a bit too much here, because their app next to Skype is the worst performing app of *all* apps I have installed.
And if you are worst at something then usually there's more then one reason to it.
And why Fb mobile sucks most on Fb? It's not because of slow animations. It's because it's completely unreliable and fetches data from network in unusually slow way. I sometimes open up a browser to go to m.facebook.com, because native app misbehaves. I'm doing it less often then some months ago, but I still on occasion do. I don't see how is this related to HTML5 at all.
Native code (objective C) will always run faster than a combination of HTML and JavaScript. However, as hardware gets faster then the difference becomes less notable. There are a number of desktop HTML5 web-apps that perform great on a decent spec PC. So, given the "write-once, deploy everywhere" advantage that HTML5 apps have, then I still think they will be the future for many apps.
Nicole Powell from HTML/HTML5 Development
Maybe FB HTML5 devs sucked worse than their iOS native devs, so they released the iOS app because it simply came out better.
If FB isn't running 3 or 4 parallel development teams, with their resources, they're just wasting time. Money they've got covered, but time runs the same for everyone.
An important reason is that native iOS apps which embed a web browser, like the older slower Facebook app, only has access to a much slower JavaScript engine than Mobile Safari. If you want fast HTML5 on iOS you have to use the actual browser, not wrap a browser session in an app.
Facebook strategy: let's blame it on Bret Taylor, since he left company
Quite interesting, because i can exactly remember the point of time when Facebook shouted earlier this year that they will bet everything on mobile (and that decision sounded quite "based on their facts").
Regarding the scrolling: That maybe true regarding what *they* are doing, but i've seen various HTML5 native apps which do it quite well.
"Maybe FB HTML5 devs sucked worse than their iOS native devs, so they released the iOS app because it simply came out better."...
So the html5 devs sucked worse than the ios devs? Doesn't that mean that the html5 devs are better than the ios devs? The ios devs suck better so there app will be worse.
The problem really is that HTML5 has not magically solved a problem that a lot of us have realised is unsolveable: That "cross platform" is really a bit of a myth. Actually the whole HTML5/JS scene really does feel like groundhog day in that a LOT of the lessons of programming history just havent been learned by this crowd. You can't just write once and run anywhere and expect it to be a good user experience. Java taught us that when we'd see companies throw huge sums of cash at "cross platform" apps only to have them rejected by users because they just didn't look native. We're seeing the inherent problems of sloppy typing turning up again and again in javascript apps because the damn language wont even let you static type. The platform has poor debugging for mobile platforms and as a result any time gained by sort-of-kind-of cross platform is swallowed by debugging nightmares, and finally the lack of optimization in UIWebViews (Seriously, the JS is mollases slow compared to the Safari browser on IOS) means you might as well be coding in something like Python that at least has a smart approach to type and OO.
If you want fast turnover and a lightning fast app for IOS at least, stick with native.
The funny thing is, they have the worst HTML code I've ever see in my life. They have 10(!) nested divs for simple things. None of them actually doing anything.
Even old table designed sites had better code. How can they be so bad?