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.

“A” is for Asynchronous, Again.

Here’s an infographic I made for my QCon talk this week, Single Page Apps and the Future of History:

I think it sums up a key point about Ajax, which is sometimes overlooked: Asynchrony. One of my first posts on Ajax, back in 2005, covered it, but it still took years to really sink in. At the time, I was thinking mostly of “Asynchronous” as XHR’s asynchronous mode, so seeing it in contrast to running XHR synchronously. But really, the big deal about Ajax is the UI can carry on, while networking happens in the background. That’s what makes filling out forms faster and what makes tools like Google Docs possible, especially in multi-user mode.

Chrome Installation Links

Some web apps on the store are promoting their web app to users visiting from Chrome, in the same way we sometimes see “Try our mobile app!” links. Why would you do this, when the user has already visited the app from a regular website? Mostly because if a user installs the app, they’re likely to keep coming back, given that it’s easily accessible from the New Tab Page. In addition, installed apps have extra powers: in-app payments (coming soon), background apps, and – in the case of packaged apps – extension capabilities. It will also help the app’s landing page on the store if happy users are leaving positive reviews.

I see all this as progressive enhancement. Each app platform has its own capabilities, some are not (yet) standard, but still expected by users. So make a normal web page that rocks, then make it rock harder for specific platforms. And let people know about it.

One size fits all? Nup. Here’s a little gallery of four sites I know who are doing this, all in different ways?

Marvel goes all-out with lightbox on entry:

HuffPo has a “Try Newsglide” message above its header:

Picnik has an “Install Picnik into Chrome” alongside Twitter and Facebook buttons:

CricInfo has an infobar on top of the page:

Apps, Bookmarks, and the Chrome Web Store

A question we get a lot about the Chrome Web Store is the distinction between apps and sites, or “aren’t these just bookmarks”? Here is my take on the topic. It’s not necessarily the official view, just my personal opinion to help you explore the concept further.

Most apps on the store are are indeed a link to an existing page on the web somewhere; what matters is the content on that page. A successful app will be visually rich, “full-screen”, task-focused, and easy to start using. For example, a link to Amazon.com wouldn’t work as an app, but Amazon Window Shop does.

The fine print:

  • I suggest thinking of the store as a place where you can discover great web apps. Need a photo editor? Search for it on the store and you’ll not only find a list of apps, but also reviews, comments, and screenshots for those apps. That preview info is much more useful than just links, when you consider that each app takes time to learn and in some cases require sign-up and payment.
  • In some cases, apps already exist and are then submitted to the web store. That’s totally fine, the important thing is if it’s a good app or not. Mapnificent was an existing website, it works on multiple browsers, but was submitted to the store and has been popular with users.
  • Some apps can gain from the publicity of launching on the store at the same time as launching as a regular website, but that’s a side issue. Also, apps like GMail – which were well known prior to the store launching – seem to attract more “but it’s just a bookmark” reactions. I think that’s just an initial reaction and will go away as users get familiar with the web store concept.
  • In other cases, apps are developed just for the store. e.g. I think (but don’t have the back story), this was the case with WeatherBug’s Weather Window, one of my favourite examples of a well-focused, personalised, rich app on the store.
  • Many modern websites fall somewhere between the richness of a Mapnificent and the traditional stature of a Wikipedia (for example). These modern sites are often good candidates for apps, but just need a little UI tweaking. So the app’s manifest should point to a slightly different endpoint, which uses a different set of stylesheets, for example, which remove most of the branding and auxiliary site info (which are gratuitous since the user has already “installed” the app). It’s also good practice for these sites to support single-sign on by implementing and checking for Open ID.
  • This being the Chrome Web Store, you can assume the platform has all the latest features of HTML5 that ship with Chrome. It’s great if your app also works in other browsers too, but it’s not a requirement. If you’re using a feature which only Chrome supports, chances are it will eventually work when other browsers introduce the feature too. The important thing is you’re at liberty not to target legacy browsers (though, again, for the right kind of app, it’s certainly still worth considering web standards and degrading gracefully; but when it comes to games, for example, not gonna happen).
  • In fact, there are actually some differences between apps on the store and apps accessed as regular websites. Firstly, I’ve been talking about hosted apps here, but there are also packaged apps, which are a hybrid of an extension and an app, and they can do more powerful things like injecting content on web pages. e.g. Fiabee lets you drag images into a special “Drop Images Here” region it embeds into the page at the appropriate time. Secondly, with the recent introduction of the background feature, hosted apps also get some additional permissions.

All this helps to answer a related question: How long will it take to build an app? The quick response might be the ever-faithful “How long is a piece of string?”, but that old pearl ducks the question, so let me make it more concrete:

  • If your product is already “Thinking In Web Apps”, stick it in the store today. (You might like to add Open ID support if login’s required and Open ID isn’t supported already.) A simple way to put it in the store is Paul’s AppMator. Typical Effort: 60-120 minutes, including time to make a quality landing page.
  • If your website is already using modern features, has modern look-and-feel, etc., you will probably need to customise the UI a bit and maybe revamp some features. You might also consider making it work offline with Application Cache, but that’s not critical at this stage. Then submit your customised app to the store. Typical Effort: 3-7 days.
  • If your website is a traditional “static” website, with minimal JavaScript and so on, and you’ve decided you want presence in the store, you’ll probably want to create a brand new app from scratch. Or maybe more than one, since there doesn’t have to be a 1:1 relationship between apps and sites. It’s actually many:many; an app can mash up multiple sites, and a site could power multiple apps (e.g. an e-commerce site could yield a product browser, a shopping cart manager, a new deals monitor, etc.; each of these is a bite-sized, task-focused app,; the best kind of app!) Typical Effort: How long is a piece of string?!! Well, it depends a lot on your existing infrastucture, e.g. do you have an easy-to-use API for your services. So depending on that, and the nature of the app, it could be anywhere from a few days to a month or more.