Was the strategy wrong, or the execution? Web vs. Native at Facebook

Folks love black and white. It is so much easier to make choices that way, and it is interesting to see people jump onto “see the Web sucks!” after Mark Zuckerberg’s interview yesterday.

Although everyone has jumped on the HTML5 comment (being the biggest mistake the company has made), there were a few other interesting comments made:

– The fact that the Facebook mWeb site has more usage than iOS and Android combined (read: the Web [reach] is still very important as an experience).

– The fact that the latest iOS application has doubled engagement (double the stories). It is pretty amazing to see a product as large as Facebook get rebooted in this way. The app looked pretty much the same (a few UX touches, but pretty minimal) before and after.

So obviously, HTML5 sucks and native rocks.

Not so fast. Let’s look at what we know from the history of the Facebook app.

Joe Hewitt single-handedly created the first version as a native application. It was lauded with praise. He created the Three20 project which had a bunch of the infrastructure that he created as he made the application. Not only were their useful components, but also some homage to CSS 🙂

Once Joe moved on to other projects, new engineers came in to enhance the iOS application and it didn’t go well. The app degraded in quality and people started to complain.

I have *no idea*, but I could imagine a mobile team forming and saying “hey, this 320 stuff is complex…. and we want to move really fast…. and it doesn’t fit in well with our architecture…. and this HTML5 thing is hot…. and we have a lot of Web devs (some of the best in the world)…. so let’s switch to that?”

Unfortunately, the “HTML5″version was not well received (even if it had more features, and if folks liked the switch to the left menu style) due to performance problems. I hated the app. It would tell me I had 3 notifications, and then when I tap to see, it shows me 2. It was always wrong, and always slow.

The cross platform strategy may have been wrong, or maybe execution was part of the deal? Having stacks of WebViews was awful. The networking was wack. Many wonder if the implementation was at least part of the problem. I have to think that it was part of the problem.

The other part was the platform itself. UIWebView sucks, and let’s not get started on the Android WebView. The platforms are not incented to fix many of the issues, so maybe the strategy was wrong due to that.

I actually like the strategy they have employed now. All out native for the experience with a “+Web” strategy. One of the real “cons” with native is that you can’t change UI presentation easily. You need to know what you want to change. What if a new type of content+action appears in the news feed… and the app doesn’t know how to display it. At this point the Web can backfill the rendering.

A hybrid native+Web strategy. That is what we employ too.

I think it is always important to remember that:
– We don’t know everything that has happened
– There is a difference between a failure due to the strategy, versus poor execution.