W2E Day 1: HTML5 with Alex Russell
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.
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.
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.
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.
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.
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.)