Sticky Points: Web v. Native Design and Design

PhoneGap has already solved this first problem actually pretty well across even more than just the iPhone. The common problems that you will run into if you do this is; one -- objection, it doesn't look native. Second one is that it is not going to feel native and third is that it isn't fast enough. Here is what we found for each of these things.

The initial mandate was, hey, you guys want to do this thing in HTML, fine, I don't want to be able to tell the difference between Objective-C rendered news feed and HTML rendered news feed. This actually didn't end up being a big problem in terms of visuals. The Web and the app actually work pretty well together. When we shipped this to users there wasn't any complaint except for one that I thought was pretty funny.

There was an iPad "app" for Facebook that was friendly for Facebook, It just simply wrapped the m.site. Some users said, hey, Facebook is copying the app that wraps its m.site as part of its Facebook for iPhone application. Which we were because we were actually just using our m.site and that was great. So, the fact that it doesn't look native, we don't actually have a big problem with that one.

Still, there are some things that you have to look out for. Position fix and overflow scroll were obviously a big problem. Android 2.1 and below, no chance. (Android) 2.2, it is starting to work and iOS 5, thank god, has promised to implement all this stuff. So, you guys are in a better position now to start down this road than you would have been 10 months ago. CSS regradients are a problem, images are a problem and [there are a couple of more gotchas].

Web v. Native Feel: Scrolling

Another problem is that it doesn't feel native and almost always this means scrolling. It doesn't really mean, hey, I want to swipe to delete. That is like, pfft, who cares? Almost always it is going to be something about interactivity and scrolling. Something that the native code does really well by using the GPU and like pipelining all that shit but it is something that it really hard to do in HTML. So, when people say that it doesn't feel native, they are going to be talking about scrolling.

Sometimes you do have implement scrolling. iScroll works pretty well, Hewitts is working on a library that is pretty good. So, you kind of have to defer to a good JS scrolling library. And, make sure you do things like resize your images because was once the responsibility of the GPU is now the responsibility of the browser. And, there are all these little things that just aren't documented, like the keyboard showing up and not closing on Android and iPhone. There are just a lot of little things that are baked into the system that are getting fixed.

The Issue Of Speed

The final one and this is the real bad one is that it just isn't fast enough. If you see a slowdown in your Facebook for iPhone application, it means that we are working through just how to make an HTML-based application work for Facebook for iPhone and it has been pretty hard.

So, tactic one is obviously pre-cache the hell out of this thing. If you render a news feed, start and going to get the content for all of those stories because when the user hits that, you want to have the content ready for them. Cache your Web views. If that doesn't work, the best thing that you can do is to just trick your users. At least have content appear to be ready. Fill out the rendered skeleton and then put in that cached content and then beneath, go get your new content. At least users will feel that there is something there because that is usually what their initial response is. A white screen is just not going to cut it.

So, gotchas in PERF means that you are going to use a lot of JS. You are no longer just loading data, you are loading pre-rendered markup, which is a lot more expensive. And things like HTTP cache and the app cache, they say they work within UI Web views but often they don't. So, you have to be really careful about promises that are made here.

Taking The Approach Everywhere

But, this worked well enough that we said we are going to put the Android app on this party train too. So, we were actually able to write something like the m.site news feed once. Any time you change a news feed story or add a news feed story or add commenting and Liking or whatever, that is going to show up on low-end m.site, high-end m.site, Facebook for iPhone and Facebook for Android the very next day, or whenever we push, which is actually pretty awesome.

So, we did do this. Now we have elements of the Facebook experience, the browser running inside everything. Especially the most volatile stuff, the stuff that relies least on a certain type of display, the stuff that is going to be evolving and changing so much, like the news feed or your profile timeline, we are doing this straight in HTML. That is where the maximum benefit is.

Next Page: How HTML5 Is Leading Facebook In A New Direction

How It Has Evolved: Heading to HTML5

So, what is the history of this? So, for iOS 3.4 and 3.5 we actually did this. Your news feed and your profile feed are actually being sourced from the m.site. So, that means if the m.site changes and adds a feature, you guys get it. If the m.site is broken, it breaks everything. There are positives and negatives there. To be launched in iOS 4.0, requests, notifications and search, this list-style content that doesn't require very specific native access, that is going to be based on FaceWeb as well. Android 1.6 and 1.7 follow the same suit. The feedback and the design have been pretty great but the bugs have been pretty crappy though. Because when you version your Javascript and things go wrong, you are tying your future to the actual Web working perfectly all the time which is something that we obviously move fast on very often.

So, the mission is to operate from one code base and adapt to all the browsers in the world. This sounds like something that Facebook would say, this is actually part of the HTML5 battle flag.

HTML5 is probably the way that we should have done it. This is the way we get to do it now because HTML5 has changed so much under our feet. The initial attempt at building a hybrid application, there were certain things in HTML5 that weren't ready yet and we said forget it, we are going to keep moving forward. The initial attempt to defer certain things to native rendering and native handling that really could be better handled by something like HTML5 and with in-browser technology - device access, good native frameworks and application and display code.

What has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?

Device Access

So, device access. Simple things like getting things that are privileged inside the device. Geo-location, network connectivity, obviously very big for caching, things like your camera and your contacts, what has changed? Well, geo-location has actually been pretty good for a while. This could certainly be HTML5 and that is what we use inside out m.facebook.com based Places and Deals stuff. Network connectivity is emerging and that is getting to the point where you can rely on newer browsers to do it via HTML5. Camera and contacts, because those are so wildly different, a lot of those things are still specified. But, if you want to look at a general list and start by asking the system for a response and getting an answer back, PhoneGap.com actually has a lot of this stuff and they have been able to this poly-fill to make a lot of this work. So, this is the easiest problem but it is the furthest along towards getting solved, especially since we have started working on this hybrid application.

History

There are certain development frameworks that are native. Being able to manage your history, it's weird. Because your history inside a native stack is very different from a browser history. Browsers are very idiosyncratic about how they handle history and it is a very different model. History management, client-side storage is obviously the big one and threading. With threading, if you guys have developed in iOS, you know there are certain things that you have to respect. That is true in Javascript as well. So, you need a good way to figure out how to get other threads to do your work and get it in a cross-platform way.

HTML5 is emerging standards to make all of this go away as well. History management, there is some good stuff in HTML5 coming. IndexDB and client-side storage is getting much better as well. Things like WebWorkers, if we did these things again, we would be able to do it in HTML5.

Can An App Be Built Now Using Only Web Technology?

Finally, I think the important thing is, could you build your app building straight up Web technologies? The actual Web technologies they are using, you are using. Scrolling, refresh, fast stuff, these are things that we had to defer to a native handler in an awkward way. But, scrolling, thank you to Apple and iOS 5 for promising that they are going to make scrolling, position fixed overflow scroll, this might be the problem of the past. Fixed position headers and good scrolling is a hallmark of what people have come to think of as a native application but it is a problem that can be solved by good JS now thanks to these new frameworks.

I think the most important takeaway is that the JS rendering engines have just gotten so much better in the past year and a half. V8 and Nitro have shown that you can build full-fledged, client-side JS applications instead of using Objective-C or Android Java and they will run and users will love them. Things like Netflix have done this very productively already.

So, the emergence and the investment of big browser manufacturers that are making really, really good JS stuff, which is finally paying off. And if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have.

Move Things, Break Things, Fix Things Fast

So, we have been following what was available to us along the road for us since 2006 in Facebook mobile. If the best that we can do is XHTML, fine. If we have a really good browser that uses JS and CSS fine. If we can build and iPhone app and an Android app, that is great. But, what is changing beneath us now is actually the emergence of this HTML5 standards and browsers that implement these standards. Especially around device access and the ability to write apps entirely in Javascript. We have seen a lot of benefit to writing something in HTML. All of our developers are good at HTML. Only a few of them are really good at Objective-C and Android. We are able to make our Web developers the same as our client-side developers in some respects.

Being able to write it once today and ship it tomorrow? That is something that Facebook is really good at and that we love doing and that is at the center of being able to move fast. Move fast has an implicit third clause - move fast, break things, and fix things fast. That is very difficult to do if you have already shipped your binary to Apple or Android and they have to download another version of it.