Facebook never bet on HTML5

Posted by on 12 Sep 2012 Go to original comments

I'm going to jump into the mix, but my post is short and sweet. In fact, I wrote it while waiting for tests to run.

Facebook never bet on HTML5. Anyone remember the convoluted rambling of Dave Fetterman at f8 developer conference last year? I remember being both dumbfounded and confounded by it.

So, how does this work? Project FaceWeb is an extension of this progressive enhancement idea. So, instead of the phone saying I am rendering for a WebKit browser, we send an agent that says you are going to be rendering for a WebKit UI WebKit view inside the iPhone app. So, what you have to do is detect that, style a Web code to make that work, build a bridge between the things that you want to write to interact natively with the Objective-C, say in Javascript, then build HTML pages for Facebook in the iPhone. So, you build much smaller native goop instead of having to build over and over again.

...

HTML5 is probably the way that we should have done it.

Near as I can tell, Facebook invented their own PhoneGap (i.e., FaceWeb) and sent m.facebook.com to it, then FaceWeb changed webkit's rendering logic* to match m.facebook.com instead of changing m.facebook.com to a mobile HTML5 site? That's not HTML5 - that's just stupid.

* UPDATE: as pointed out in comments, this isn't exactly accurate. Faceweb does some funky stuff though, and their engineering manager in charge of the project couldn't even articulate what it is. So it still sounds like bad engineering unrelated to HTML5.

* UPDATE 2: You should read Matt Asay's analysis of Facebook's HTML5 fiasco. In fact, you should read everything Matt Asay writes.

Question or comment about this post? Tell me on GitHub.

Facebook never bet on HTML5 / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA
dev tech greatest-hits
  1. Kethinov 2012-09-12 14:11:36 -0500
    They didn't change webkit's rendering logic. All they did was add JS APIs so m.facebook.com could make calls to device APIs using a bridge code like PhoneGap inside their native apps. There's nothing wrong with that approach at all. Lots of apps do it and it works fine. The real problem with Facebook's web efforts is their web coders did a shoddy job optimizing for performance. That's all.
  2. Erik Harrison 2012-09-12 15:26:26 -0500
    I'm reading this and it doesn't actually seem as insane as you make it sound. Maybe I'm missing something, but it looks like pretty standard progressive enhancement. They build m.facebook.com for their lowest end target (feature phones), then send a javascript blob to upgrade the functionality of all the bits. The weirdness is that they JS blob talks to some native bits of the OS API that is bound to JS in the app. That requires an extra round trip to the server to get the blob, when it could be exposed in the app itself, but this way they don't have to update the binary on the phone as often. It's not "pure" HTML5, but what is?
  3. groovecoder 2012-09-12 16:25:50 -0500
    Good points. Updated post to reflect. It still sounds like shoddy engineering unrelated to HTML5. i.e., Facebook bet everything on FaceWeb, not HTML5.
Facebook never bet on HTML5 / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA