James Pearce on Mobile Web: More QCon Live Blogging

Sencha’s James Pearce explains why HTML5 rocks mobile apps.

Benefits of the web for mobile apps:

  • well understood
  • cross-platform
  • familiar skills and tools
  • decentralised
  • easily updated (no store process)
  • indexed
  • well understood

Mobile is about to explode – where the web escapes and comes with us, to the car and walking around etc.

Same way you had to sit down and listen to the record player instead of having music mobile. “I can’t believe you had to sit down to use the web”. Use it like a phone, e.g. avoid long forms, make phone numbers clickable, don’t include word docs!

The Web is evolving:

  • Web of documents is becoming a web of applications
  • Declarative HTML becoming programmatic DOM
  • Templates becoming APIs on the server-side
  • URLs becoming arguments (ie command-line)
  • RequestResponse becoming synchronisation

The HTML5 mobile stack looks basically like a native mobile stack

Browsers are much stronger these days, including IE9’s effort. But nevertheless, there’s still a range of varying support for the browsers.

So can’t rely on everything, but some features are there now and diversity is something web developers do have to live with. These tools help:

  • http://caniuse.com
  • http://modernizr.com
  • http://deviceatlas.com

Many mobile frameworks around: * Sencha (James’ company), jQTouch, jQuery Mobile, Sproutcore, * xui iui zepto embedJS …

James walks through some of the frameworks. Compared to jQuery mobile, Sencha is more of a pure client-side library – less reliant on a server outputting HTML. Tends to be more script focused than markup. In an MVC way.

Demo: http://sencha.com/x/5e

What W3C calls Thematic Consistency – should get same content on different devices, even if laid out differently. Lots of possibilities – e.g. do you have a special mobile version.

We can have user interface, business logic, and storage on the client; and security and storage on the server.

Whoa – security on two sides means we have a new problem for the web. Storage on both sides. But it’s a well-understood problem outside of the web.

Mark Miller on Securing JavaScript: More Qcon Live Blogging

Google Research’s Mark Miller is presenting a talk on Caja and web security. He emphasises that this is all bleeding-edge; no current browser fully supports this yet.

There are a ton of attack vectors for browsers, as shown on the Caja wiki. There are spec vulnerabilities, implementation vulnerabilities, and an ongoing arms race emerges. Mark shows a table of numerous variables for each browser, where the variation is not just wild but more or less random. The attacker only need to find one vulnerability here.

Perhaps the ongoing cat-and-mouse game means there’s something wrong with the whole identity-centric paradigm. Instead, maybe we can look at access control – don’t worry about who’s sending the request, worry about if the request has the correct level of access.

Mark walks us through the history of web kludges – JSON and Comet for cross-domain calls and streaming, respectively. HTML5 gets us towards a truer web of distributed objects, which all leads towards a symmetric network.

Safe Mobile Messages: Uniform XHR

Uniform as in “Uniform Resource Location”.

The proposal is for the server to ignore browser’s “helpful” extras.

Authorise based on payload. HTTPS URL or request body – info the requestor knows.

HTML5 allows servers to waive response protection using “Access-Control-Allow-Origin: *”.

Mobile Code

How do you mix coded from multiple untrusted sources into the same frame?

To solve this problem, we bring other security models to the world of JavaScript. With EcmaScript 3, Caja had to perform complex, server-side, translation with a runtime overhead.

The lessons of this effort were taken to the Ecmascript committee, and accordingly, EcmaScript 5 is one of the easiest OO languages to secure, instead of one of the hardest, as was the case previously.

Security as Extreme Modularity

This view treats security as an extreme form of modularity (ie the mutually suspicious components are seen as modules). Vulnerability is a form of dependency…so improving security also helps in other aspects, ie. makes the architecture cleaner.

So we marry up these closely related principles: * Software Engineering Principle of info hiding: Need to know. * Security Engineering Principle of least authority: Need to do.

These are the rules enforced: * Memory safety and encapsulation * Effects only by using held references * No powerful references by default

Objects as Closures


  1. function makeCounter() {
  2.   var count=0;
  3.   return {
  4.     incr: function() { return ++count; }
  5.     decr: function() { return --count; }
  6.   };
  7. }

A record of closures hiding state is a fine representation of an object of methods hiding instance variables.

With “use strict”, we can enforce freezing of values. So if you have object A which depends on object B, object A can freeze properties of object “B” to make sure the reference doesn’t change. An important aspect of this is the ability to feeze a prototype.

For now, we have the “initSES.js” library. It monkey patches away bad non-standard behaviours, freezes whitelisted global variables…among other measures.

There’s a concept of membranes (wrappers) to encapsulate/secure message passing. e.g. if you don’t trust object X, you can make a read-only version of its return value. It’s also possible to wipe out what’s inside the membrane at some later stage, if desired. Even if that thing had references to external objects, only what was inside the membrane will be wiped.

Live Blogging at QCon HTML5 Track: Dave Recordon on HTML5 at Facebook

I did my talk on Single Page Apps and this morning at QCon today on Single Page Apps and HTML5 History. The demo raised a number of interesting design principles/patterns which I’ll cover in a later post…but for now, I’m going to post a few live blogs from sessions here. [Update – AlBlue’s posted a summary of talk.]

First up, Dave Recordon explains how HTML5 is being used at Facebook.

Dave Recordon explains he works with Facebook’s developers to promote web standards and HTML. What is the promise of HTML5?

He begins by asking the obligatory, “What is HTML5”? His definition agrees with mine – not just a spec, but the technologies that let developers make awesome apps, and a brand that developers can rally around.

HTML5 at Facebook – Today

While some say HTML5 isn’t ready till 2025, Facebook wrote on their blog about “Using HTML5 Today”, a look at a bunch of things they’re already working on:


Facebook has a framework called Big Pipe which loads the overall page structure, and then a second structure called QuickLink which overloads links to reload just parts of the page. This led to ugly URLs, with fragment IDs e.g. http://www.facebook.com/profile.php?id=24400320#!pages/Engadget/5738237369, and history gets them around that.

Recently, they created a new photo app which involves photo sharing and lightboxen to show the photos.

window.history.pushState(“http://facebook.com/full/url/to/photo”, null, “http://facebook.com/photo.php?fbid=123456678 ….”);

Web Video

Dave explains that Facebook hosts a lot of web video, and there’s no clear way to deal with it rigt now because of codecs…but, he says, it’s fair to say most people today would go with H.264 or WebM. Today, H.264 is Safari and IE, WebM on Chrome, Firefox, IE, and Opera. This difference, as well as DRM, is one of the reasons why people are still choosing Flash for video.

Dave bigs up video.js as a way of dealing with the complexity, and says they’re still using Flash for the most part, with the following advice:

  • Use your own Flash player if you’re already built one.
  • Use the same size poster image, raw video file, and Flash player.
  • iOS devices only support H.264.
  • Storage for double (or even triple) encode become costly, quickly.

Sprites and Gaming

They analysed the requirements for gaming. 10fps gets you minimum interaction for a game, but really you need to focus on 30+ frames per second, so this is where they focused. How many sprites do you need for a game? 5 sprites for a simple baord game, leading up to 100 for a 2D game (that’s the scope they focused on). They found the modern browsers can deal with the requirements well, e.g. with WbGL, Chrome 11 can handle 4000+ sprires.

He walks through various options for showing a spaceship. Just an image? A sprite? But if so, a div with a background image or a mask over the big sprite sheet image. They’ve done research to this end.

See http://github.com/facebook/jsgamebench


Hundreds of millions of people access Facebook from their phones, so Facebook’s looking into how HTML5 can help here. Which platforms do you need to target?

  • Features phone
  • iPhone
  • Android
  • BlackBerry
  • Palm Pre
  • Windows Phone 7

Dave says that even for Facebook, let alone a startup, it’s hard to keep up with all these devices. The wurfl project maps devices to capabilities (e.g. does it support JS? what screen resolutions?), which Facebook is using and feeding data back into it.

The popularity of WebKit makes it easy to target multiple devices at once, and this is apparent in the way PhoneGap works to let you target multiple devices in the one go.

Assorted Questions

Dealing with IE6?

Decided not to support chat on IE6, but generally try to support older browsers as well, simply by way of the numbers.