Don't Make Facebook's Mistake, Architect for the Modern World

A few months ago Mark Zuckerberg made headlines all over the place when he said HTML5 wasn't there yet and announced Facebook would be going all native with their mobile applications. As someone who believes whole heartedly in the ability of HTML5 this never sat well with me. As I had time I did some research into what areas Facebook encountered problems. I mean their iPad, iPhone and Windows Phone apps (the ones I am most familiar) were pretty simple, so I could not get my head wrapped around why their application was not 'good' or how they could have messed up the implementation in HTML5.


According to information released by one of their engineers, Tobie Langel, it was about poor experiences with their infinite news feed as well as mobile browser tooling. As I read his comments I also could not help but hear him stating Android is the big problem. I agree with the Android sentiment, the new IE6 problem. But as for the animations, memory and other 'black box' issues I never really felt like they should be an issue. Personally I have dealt with all those issues, many times over and I know they can be frustrating, but they don't have to be limiting.

Last week the Sencha team did a great job proving my point, HTML5  and CSS3 are not the real issue. The real issue Facebook has is poor application architecture. In fact they made a good case for why most web sites are just not acceptable in the modern world, they are written to be good a decade ago, when slow and laggy was acceptable. Today standards have been raised, thanks in large part to the rise of native iOS and Metro UI apps (yes I did not include Android, they lower the bar in my opinion).

For the record Tobie Langel, the Facebook Engineer made these points about mobile HTML5:

  • Tooling/Developer APIs
  • Scrolling Performance
  • GPU
  • Other

I agree, accessing information about what is happening on the device is tough. Android probably has the best experience for this, but it takes some effort. The latest version of mobile Safari also has some rich debugging capabilities, if you own a MAC desktop. Generally I tend to work out the application parts on the desktop, knowing mobile constrains the experience more. So I tend to spend a large amount of time optimizing the client experience on the desktop then deploy to test on a battery of devices. It takes more time than we are traditionally used to allotting and there is no F12 support. I would love better tooling, but I can work around it most of the time, it takes some patience and imagination.

Good scrolling can be a booger. I have been working on this and think I will wait to provide a more detailed study on ways to achieve quality mobile scrolling. The GPU is a black box, and honestly I feel like it is on the desktop too. I guess I don't worry about it that much. I know I can flip some Chrome settings to visualize how the GPU is being applied, but I rarely do. I know CSS3 transforms do a pretty darn good job.

The Other section touched on poor implementation of touch on Android, reiterated his beef with poor animations and talked about caching. I have a pretty darn good strategy around caching in modern web apps thanks to localStorage and IndexDB. I also agree with him about applicationCache being busted, which is why I developed my caching strategy. If you have seen me present over the past you have seen me demonstrate this in action.

As far as touch on Android goes, see my previous comments. He is correct, Android is a poor user experience, no doubt. And please don't tell me you have a Galaxy SIII and things are great. You are an extreme minority as most Android uses are using version 2.X, and the number 2.X activations only increases everyday. And I have Jelly Bean installed and I am not impressed with it either.

Which leads me to the main point of this post, the problem with Facebook's HTML5 strategy is their overall application architecture. I love what Sencha did:

"We connected an iPhone to a web debugging proxy, and started to look at the HTTP traffic the application pushed over the network. Our biggest shock: much of the application was still raw HTML pages."

The funny thing was I did a similar experiment the week before Sencha published their findings and example site, I simply monitored the HTTP traffic using the IE and Chrome F12 network monitoring. If you filter out all the image requests, which are just part of viewing your news feed. You will see a lot of requests for text that are over 100kb each. Looking at the content you find large chunks of markup, JavaScript and the small amount of actual text that needs to be rendered on the page.

Here is an example snippet from one of the requests I saw while writing this article:

<html><body><script type="text/javascript">document.domain="";</script><script type="text/javascript">if (parent.AsyncRequest) {parent.require.......

This of course goes on for a while and is repeated over and over as you scroll through the news feed. What Facebook and you should really do when building any modern web application is make an AJAX call and get JSON. Merge that JSON using something like jQuery templates and bind the new markup in the DOM. This is way more efficient than requesting copious amounts of data over and over again. All the markup should be already available on the client in the form of templates. I store mine in localStorage or IndexDB. The JavaScript needed should also already be available on the client, so no need to render on the server and send down the pipe, the browser's JavaScript engine, even on the cheapest Android can adequately handle this task.

The Facebook infinite scroller does create another problem, one Langel referred to in his post, eventually you hit memory pressures and the browser simply crashes. Even on the desktop you need to care about his because a large DOM kills performance. So for an infinite scroller you want to remove unneeded DOM elements, in the case of the infinite scroller this would be elements that are far enough off the screen to not be accessible with a few finger flicks. The Windows 8 ListView takes this into account and utilizes a solid virtualization management system.

Again if you have seen my presentations over the past year you have seen me do this swapping views for my Single Page Web Apps. If the view is not 'in view' then the markup is removed. I build and inject markup as needed. This keeps my DOM small and the memory footprint small as well. Another thing is I don't keep large amounts of data in JavaScript variables. Again I keep the data in localStorage or IndexDB and grab it from there as needed. This is important to maintain a high level of performance, especially over the course of the day, Which can be a real issue with enterprise line of business apps. This is only of the big reasons why I will not use MVVM and things like Knockout.js because they rely heavy on in memory JavaScript variables that can easily grow very large in a single page web application.

Covering what I consider good modern web application architecture is much more involved than what I can cover in one post or even a series of posts. I encourage you to read the Sencha Fastbook post because it details many good practices with a real example that implements them. I applaud them for doing this because I simply don't have the time, but knew someone would do something to disprove the Facebook claims.

Shame on Facebook for poorly architecting their application and blaming it on HTML5. They could have done a much better job building their application. Sure they would have still determined Android is a problem, but they could have done a good HTML5 application regardless. There are still some issues I have with the way HTML5 is or is not implemented at this point and I have written about that. I blame the browser vendors for this, they need to implement the full spectrum of device APIs and be bold about it. As developers and architects we have to do a much better job architecting our modern web application experiences and let go of the techniques we used in the past, they are no good anymore.

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel