I Am Not Charles


W2E Day 1: HTML5 with Alex Russell

Posted in the Living Room by Joe on September 27, 2010
Tags:

First impression: some guys behind me talking about which smartphones they should get for testing. “Not a Blackberry, though – I can’t stand doing web development on the Blackberry browser.” Sob. We were vindicated when Alex listed the browsers that could and could not handle HTML5 features, and carefully split BB into “Torch+” and “pre-Torch” in each list.

Second Impression: wow, dense. This was a dense, dense, dense, dense talk.

The first part of this talk was basically, “A browser engineer tells you how to build web pages.” Actually Alex’s epigram for it was more illustrative: “Think about your web pages the way a browser thinks about web pages.” About time! You wouldn’t believe how many optimizations we have to bypass because it would break some ridiculous crufty feature that page authors nevertheless make heavy use of. Like Javascript.

Many web developers just don’t realize how many side effects common techniques have. The most obvious is that Javascript is executed as soon as it’s parsed, and it blocks page loading until it’s finished. But Alex went through some more obscure and situation-dependent ones: for example, reading computed style info from Javascript requires the engine to do a layout pass to compute that info, which can be very slow, unless it’s already been done. So try to delay Javascript like this until after the page has already been laid out and rendered once (good luck reliably figuring out when that is.). You especially want to avoid Javascript that alters the page structure, forcing it to be layed out again (unfortunately, this is the most useful thing for Javascript to do).

Another extremely important thing that’s often misunderstood is just how much DNS sucks. Because DNS is a giant bottleneck, and for other reasons that Alex went into at length but I won’t because this is long enough, opening an http connection is heavyweight, so for good performance you want to avoid downloading lots of small resources: put as much as you can into each resource, and try to prioritize so that the important ones (CSS that applies to every element on the page) doesn’t have to wait on the tiny images that form the rounded corners of your logo.

Hopefully the talk went into enough detail on this to give the audience a good conception of these issues. But I think it might have been a bit heavy on the browser developer jargon – it included an overview of webkit render trees (!) to explain how the various bits of timing interact.

Fortunately the take-away for general design can be boiled down to some simple points: put your CSS first; put your Javascript last; and use “defer async” as much as possible. (But don’t take my word for it, check out the slides, because it’s important to understand why this helps in order to generalize it.)

I spent the opening half of the presentation thinking, “It’s great how he’s showing all these web developers the complexities involved in the browser!” But then when he started talking about individual CSS elements, I started to zone out. “I can just look these up in the spec when I need them.” I wonder if the web developers in the audience had the opposite reaction?

Speaking of which, there wasn’t a lot of audience reaction. He kept asking for questions and getting none. I think it was more of a, “This is really cool but I’ll clearly need to play around with it myself to get a feel for it, so I don’t have anything to ask yet,” kind of silence, and less of a, “I have no idea what’s going on,” silence, but it’s hard to be sure because the second half of the talk flew through a whole bunch of new HTML5 features without pausing on any of them. Too densely packed to linger. So let’s repeat the whirlwind tour:

HTML5 ~= HTML + CSS + JS APIs

HTML has some new and shiny things:

New, cool input types that let you remove validation code (they have builtin constraints) and avoid writing complex user interaction objects (they have builtin themes and behaviour that’s more complete than traditional objects).

Canvas – lets you draw on the page with inline code instead of downloading tons of images which fight for network priority.

ContentEditable – turns any HTML element into a rich text editor.

CSS has more new and shiny things:

Gradients, shadows and rounded borders: again, less use of images.

Layered backgrounds so you can draw your background with a canvas instead of, again, an image.

Transitions for hardware accelerated page effects without writing and parsing Javascript.

Transforms for morphing the display of items (although they’re not available everywhere, so use judiciously).

Animations for even more elaborate (and hardware accelerated!) page effects, although they are probably not finalized as the syntax is still not very clean compared to transitions.

Javascript and the DOM have new things that are less shiny, but useful:

First, let me digress to talk a bit about jQuery. It’s a horrible anchor around the neck of every web site. It’s a gigantic library that must be downloaded and parsed (synchronously) before even beginning to parse the rest of the page, and because everybody uses a slightly different version of it served from a different URL they can’t even share a cache of the thing! The only thing worse than using jQuery is not using it: can you imagine the bugs that would be caused if everyone tried to duplicate its functionality by hand?

So replacing jQuery with something making better use of inbuilt browser features is a worthy goal, because it would hit points (a) and (b) above perfectly.

So when Alex says, “These new features let you do everything jQuery does in 30 lines of code!” I prick up my ears. Not being a web developer, I don’t know what jQuery actually does, so I’m probably being naïve, but here they are:

querySelectorAll is a new DOM method that ties in with the CSS declarative model: give it a string and it will return all the nodes which match that CSS declarator. As I mentioned yesterday, CSS is not my thing so the descriptors Alex demonstrated were all gibberish to me, but the concept seems pretty useful.

defineProperty is a new Javascript statement that let’s you add functions to any prototype, meaning if you stick something on the root of an object tree, it’s automatically available to every derived object (what most languages would call a “subclass”). This has always been possible, but there were side effects that made it dangerous to use in libraries; defineProperty does it cleanly.

Some more Javascript goodness:

WebStorage let’s you store persistent key-value pairs. Traditionally you would use cookies for this, but cookies are terrible for performance: they’re included in the headers sent with every request and response, and the headers can’t even be zipped. And incidentally, the cookie “spec” is a joke (it is fundamentally ambiguous, so it is not possible to write an algorithm to parse cookies correctly) so anything that gets rid of them is A-OK by me!

Drag and drop is traditionally done with fragile and inefficient Javascript; now it’s built into the browser.

And, uh, some more, but by this point my notes are becoming illegible because my God that’s a lot of stuff. And there are a lot of intriguing points brought up about all of these, which this margin is too small to contain, so if I have time I’ll make more in-depth followup posts on some of them.

Of course, you can only use these features on bleeding-edge browsers – so, well, basically all of them except IE 6 to 8. Which still make up something like 30% of the market. Alex handwaved this a bit by talking up his Chrome Frame product – you can just ask your users to install an IE extension instead of a whole new browser – but it sounds pretty tenuous. I have no better solution for this, though – adding fallbacks defeats the whole purpose of using new builtins to make pages smaller and simpler.

Then there was a lab session, which Alex unsurprisingly ran out of time to show in detail. It showed a small sample app using these techniques, including a wrapper library called h5.js which makes using some features simpler, works around design flaws in others, and includes an async downloader for resources in less than 1K (gzipped). Source code is available here.

All in all, a very impressive presentation, covering lots of exciting ground, but could have used a little less scope and more depth. Fortunately, the afternoon’s session provided a very nice complement.

(While I’m attending this conference on behalf of Research In Motion, this blog and its contents are my personal opinions and do not represent the views of my employers, colleagues, family members, or pets.)

2 Responses to 'W2E Day 1: HTML5 with Alex Russell'

Subscribe to comments with RSS or TrackBack to 'W2E Day 1: HTML5 with Alex Russell'.


  1. [...] was a good companion to this morning’s session (okay, yesterday morning’s session now: Alex’s workshop took so long to write up that [...]


  2. [...] committee, and Javascript evangelist at Yahoo Alex Russell, whose workshop I already went to on day 1 Brendan Eich, original inventor of Javascript and Mozilla CTO Håkon Wium Lie, creator of CSS and [...]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: