Wanting to explore WebSocket, I made a demo that syncs videos for all users looking at the page (See the Code). Any user can "take control", so that the other videos will follow the controller's video. Writing it was a cinch with the Javascript WebSocket API in the client, and the very straightforward Node WebSocket Server powering the server.

Note it's just a simple demo - there's no security model here and there's a very simple sync mechanism: When a "slave" client receives the latest duration, it adds a second to account for lag, and moves the video iff there's a 5-second discrepancy.

How does a WebSocket client look? Well, it looks a lot simpler than a traditional Comet client. Initiate the connection with "new WebSocket":

Upload a message to the server with send():

Receive a message from the server with conn.onmessage():

And when it's time to draw the curtains, close the connection with another one-liner:

The server is also rather tiny. It mostly just broadcasts (sends to all clients) any incoming message and it's up to the clients to deal with it. Which is why I say there's no real security model here.

As you can see in the above snippets, "video" plays an excellent cameo role here, with its equally simple API. One downside, which others have mentioned too, is the lack of styling in the default video controls. It's great the API supports automatic controls, but it's unfortunate there's no CSS manipulation. In this case, the "slave" browsers should be able to see the time, but not have the ability to change the progress. I hope this changes in the future, because the API is otherwise very powerful without compromising simplicity. Until then, libraries will arise to fill the gap.

The demo works in both Chrome and Safari (and they play nice simultaneously).

Browserscope is a very cool tool coming out of Steve Souders' performance efforts and being developed by Steve along with Lindsey Simon. It's part of a trend towards crowdsourcing browser info, in similar vein to TestSwarm, for testing specific code, and along the lines of what I did with WebWait, which is to support multiple people benchmarking a website at once. (Though I've not set up reporting on it - one day...)

So anyway, Browserscope began life as a way to benchmark just performance, but is now a general-purpose tool for crowdsourcing tests about anything browsers do, e.g. checking for security vulnerabilities is one vital application. HTML5 does not miss out - HTML5Test.com has been ported over too - see beta.html5test.com.

Geolocation Test

I decided to make my own test recently, to see what extent Geolocation is being supported by the browsers. Run the test against your browser here (it will upload only information about whether geo is supported, not your actual geolocation data):

http://test.mahemoff.com/geo.html

The results so far indicate browsers either don't support it, or support accuracy+lat+lon. I was hoping to see at least direction, and would <3 to see altitude! But it will have to wait.

How to Make your Own Browserscope Test

If you ever wanted to know how every browser under the sun handles a particular something, Browserscope is your new hotness. It makes it trivial. Register with Browserscope to get the boilerplate code. Then you just write an app that does the exercises and builds up a hashmap of the info you want to collect, and BAM, submit it. The hashmap should have values between 1 and 1000. Do that, and you'll end up with a nice summary page showing your test results aggregated across all browsers that ran them.

The submission is taken care of by some boilerplate code - it uses on-demand Javascript to pass the data back to the third-party BrowserScope domain (you host the test yourself). Aside from writing the actual test and promoting its location, the only thing you have to do is make a nice UI to show the users what you just did, and perhaps get their consent before uploading. I think those are actually two things Browserscope could automate too, at least providing a nice default UI which test creators can customise.

There's not much to say about Web SQL - you either know SQL already, in which case it's fairly straightforward and just a matter of squeezing your SQL calls into the conventions of the API, like any other SQL framework as, lamentably, there's never been any kind of standardisation on the wrappers that go around SQL - or you don't know SQL, in which case there's your bottleneck child if you intend to use Web SQL Database for offline storage.

Web SQL Database lies at the other end of the complexity spectrum from Web Storage (aka localStorage and sessionStorage), which is simply a big ol' hashmap for your domain. The complexity is fairly manageable, though, as there's literally a generation of SQL know-how out there, and hopefully ActiveRecord-like libraries on their way.

IndexedDB promises to offer a third way - more like the hashmap approach, but with some of the indexing-based performance gains SQL has to offer. No browsers have implemented it yet, though you can build an experimental windows version using a third-party Firebreath implementation.

Google I/O is over and I'll post a bit about the HTML5 hack session I ran later, but here I want to highlight a couple of upcoming sessions in Europe:

UXCampEurope. If this is anything like the Bay Area and London UX camps I've been fortunate to attend, it will be huge, and being Europe-wide and in Berlin, this expectation might just be met. I was sitting on the browser along with @mattlucht hitting refresh 10 times a second when the tickets were released at the start of the year! I'll set up a slot called "What did HTML5 ever do for users, anyway?". I'm planning to overview some of the features of HTML5 and its evolution from Ajax, and ask how it might be used to improve UX. It's a camp, so I'll also be hoping to collect contributions and writing them up somewhere.

SWDC. The first Scandinavian Web Developer Conference and Peter Svensson is organising, so I know it will be an awesome event, and the sessions speak for themselves. I've bumped into the guy twice in the past month - he travelled from Stockholm to DC for JSConf, and again to SF for I/O. My session is on the mobile day, called "HTML5 Gives You Wings", focusing on HTML5 techniques for performance and app-like behaviour. Here's the summary:

Welcome to the dynamic world of mobile development, where new browsers stay close to the edge and HTML5 is already a reality. Despite the impressive advances, many mobile apps are still bottlenecked by the network and compact processors continue to lag behind their desktop counterparts. So how can HTML5 help? This talk will focus on those features of HTML5 that are interesting for performance optimisation and the techniques for emulating native apps, such as offline data storage.

Quickstart an Offline App

As with most HTML5 technologies, the basic usage is quite simple:

1. Create a trivial trio of HTML, CSS, and JS files, maybe with an image or two. (Or reuse an existing toy app.)
2. Link to a "cache manifest" file from your HTML file's html tag like so:
   PLAIN TEXT
   HTML:
   

   1. <html manifest="clock.manifest">
   
   
3. Make the manifest file. It's just the literal phrase "CACHE MANIFEST" on the top line (I know, bit random), followed by the list of files in your app:

   CACHE MANIFEST
   clock.html
   clock.css
   clock.js
   clock.png
   

4. Mark it as MIME type text/cache-manifest. If you're SSHing to a virtual host (like I did with Dreamhost), all you need here is a one-line .htaccess file:

   AddType text/cache-manifest manifest
   

That's it. Now those files above will be cached locally and won't need to be downloaded again next time. To test it, load the site, shut down your net connection, and reload. It's still there innit.

It works the same on your app-phone - on iPhone or Android (or others maybe), load the site, switch to airport mode, go back to the browser and reload ... the site's still there. Where it gets really fun is making it into a regular app:

• On iPhone, bookmark the site with the Safari "+" button, choose "Add to Home Screen", and the app will be sitting alongside all your other apps on the home screen.
• On Android, bookmark the app in the browser. Hold your finger down somewhere empty on the home screen, choose add "Shortcuts" | "Bookmark", and choose the bookmark you've made.

You could do the same with any website of course, but it's particularly cool when the website is an offline one...it works just like a regular app!

Practical Tips and Troubleshooting

Purging the Cache

In practical terms, you are quickly going to come up the no. 1 problem of developing against a cache. How do you purge it whenever you update your code?

Simple. You only need to make an arbitrary change to the cache manifest file, so just include a version number in the comment:

CACHE MANIFEST
# v1
clock.html
clock.css
clock.js
clock.png

Keep revving it up every time you change any file, because changing those files alone won't have any effect. And if it's getting serious, you'll want to practice the principles of DRY and continuous integration by automating this process.

Ridding yourself of Errors

An unfortunate thing happens when there's a downloading error: The whole thing silently fails. Until debugging tools get better, if you find your app's not updating, you ought to check each of the resources specified in the manifest really, really, carefully.

Cached Resources

Cache manifests are not exempt from standard caching rules, so the manifest itself, as well as other files might be cached. Pain. A good solution is to use the following Apache directives to .htaccess:

ExpiresActive On
ExpiresDefault

That MIME Type

Things might fail if the Cache Manifest MIME type is wrong, so use your browser's debugging tools or a service like Web Sniffer to check it (thanks CSS Ninja).

The Wording

The wording can also trip you up. Be really sure it's exactly "CACHE MANIFEST" at the start of the file. Again, better debugging tools in the future will help here.

The Fancy Stuff

All of the above is enough to get up and running with an offline app, and maintaining it too. But wait, there's complexity too!

Fine Control Over What Gets Cached

The cache manifest file actually allows three kinds of resources:

• Online resources that can be cached (CACHED). As shown in the example above, it's the stuff that's available for caching.
• "Fallback" resources in case a file isn't cached (FALLBACK). These are like catch-all email addresses; any resource that's not cached, is a candidate for a fallback. There's a pattern-matching algorithm to map resources (which mightn't have been cached) to other resources (which hopefully have been cached). For example, you probably wouldn't cache every wikipedia article, so the fallback section would ensure a special "offline.html" page is shown for those missing articles.
• Online-only resources (NETWORK) Resources which should never be cached, e.g. it would be a good idea not to cache stock prices if people were making million-dollar decisions on the back of what they see on your possibly-cached web application.

The syntax (adapted from the WHATWG example):

CACHE MANIFEST
# a comment
# v37
# (version number unnecessary
# but recommended for cache purposes)

# the following "CACHE:" is optional; # a special case because top of file # is cache by default # CACHE: images/sound-icon.png images/background.png # note that each file has to be put on its own line

FALLBACK: / /sorry-i-am-offline.html

NETWORK: /stocks/*

Checking if We're Online

window.navigator.onLine ... try it now in your console (and try it again with your connection off).

Monitoring State and State Changes

What do you notice about all the app cache stuff above? It's all declarative, no Javascript. But you can go on to do extra stuff with Javascript too, via the Application Cache API. (I am somewhat skeptical about the applications for this API, since simple and declarative is the way to go for something as potentially hairy as offline...but that's for another rant.)

The window is effective tied one-to-one to the cache object, so you can just access the cache with window.applicationCache. For example, you can get cache state with window.applicationCache.status, try it now in your console. It will probably be zero...the possible values range from 0 to 5, representing: UNCACHED, IDLE CHECKING, DOWNLOADING, UPDATEREADY, OBSOLETE. (These constants are also available on the cache object, i.e. window.applicationCache.UNCACHED is 0.)

There are also event handlers to monitor event state: onchecking, onerror, onnoupdate, ondownloading, onprogress, onupdateready, oncached, onobsolete.

Forcing Updates

applicationCache.update() will force an update, i.e. start downloading the application again if the manifest has changed. However, it won't suddenly switch over after downloading. To do so would be to pull the rug from under your live, running, application. It will be there next time. But if you do want it right away, use applicationCache.swapCache().

Offline Mobile Apps: It's More than Application Cache

Application cache certainly is a critical feature of mobile apps; it's a basic user expectation that a mobile app starts right away, unlike a complex web app which must be downloaded. However, there are other things too. For example, offline storage. That's another feature of HTML5, comes in many incaranations, and something for another day. The other really big deal is the UI. Of course, you need to simulate certain UI features of the native apps if you want your web app to go native. Hence, libraries like IUI, jQTouch, and Apple's secret PastryKit. On the input side, your UI must also handle touch events, something some of the aformentioned brand of libraries will support. Finally, there will be specific features of the platform that can help; for example, setting the home screen icon and going full-screen so the browser chrome doesn't show up.

This is a gotcha that will catch a lot of people out because it goes against the expectation that you just change an image's appearance by setting its "src", done. And also, it's a deviation from the more general convention that you change DOM properties declaratively to make stuff happen. Probably for good reason, given the temporal nature of audio and video playback, but just beware it's a different model.

Bottom line is - load() between changing src and play()ing:

A lot of online sources talk about play() and omit to mention this vital fact, because they're only play()ing a single track...and the first track works fine. This is an oddity - you can just call play() the first time and it will automatically load. This happens whether you set "src" in the initial HTML's "audio" tag or whether you set it programatically. I did some fiddling and it looks like the behaviour is the same in Chrome and Firefox. It's like the track is auto-load()ed the first time you set its source. (And note that Firefox doesn't auto-buffer so that's nothing to do with it.)

devx has you covered on this topic, and points out the subtle issues which you would need to look at for a quality production:

However, media by its very nature is a time-spanning process. You're working with both the need to load and cache audio and video files and the network connection, which itself can prove to be a challenge that's usually not a factor for most non-temporal resources. For these reasons, when dealing with video and audio on the web, if you want to take control of the process in any way, you have to work asynchronously, tying into the various events that are passed back to the client from the media-serving website. Table 4 (taken directly from the HTML 5 documentation) provides a full listing of the various events and when they are dispatched. ... Of all the events in Table 4, perhaps the most useful are the canplay and canplaythrough events. The first, canplay, will fire when enough data has been loaded for the video player to start actually rendering content constructively, even if not all of the data has been loaded. The canplaythrough event, on the other hand, will fire when the data has essentially completely loaded into the browser's buffer, making it possible to play the video all the way through without the need to pause and retrieve more content.

This here is a script that will put the code of all scripts and stylesheets into a single variable. Usage:

As you can see, you have to provide a callback because this stuff is asynchronous. It downloads the files one at a time to keep things simple and without using any fancy-pants Ajax queueing library. And right now, timeouts won't be too graceful. Also, browsers will typically allow scripts and stylesheets to work cross-domain, but of course XHR won't. So any external scripts and stylesheets are unfortunately out of reach and will not be captured. This is an especially tragic circumstance in the case where they are hosted on a different subdomain. But, as they say, "hey". I don't know what that means, but, as they say, "hey".

Yoink will download inline scripts (script tags with bodies), remote scripts (script tags having a "src" attribute), inline style attributes (elements having a "style" attribute), inline style tags (style tags with bodies), and remote stylesheets (links of type "text/css").

There are several purposes. I did a quick hack version of this a while back to improve logging info; in principle, a logging method could introspect on the source tree to show extra context info (locate the log message I'm currently outputting, and then say which line it's coming from, for example).

In the case of Single Page Applications a la TiddlyWiki, a plugin might use Yoink to inline all the remote content.

Right now, I'm more interested in using it for browser extensions, such as the Feature Creep extension I suggested, to show what's happening on the page. Some of that stuff you can work out by inspecting the DOM, but other stuff ... show me the code!

Get it here - http://gist.github.com/378850. Shown below for convenience:

THE LOST HACKS: Ridiculous browser tricks from the world of single-page Applications

The talk will overview TiddlyWiki and Single-Page Apps, and then cover eight specific hacks:

• File access without browser extensions
• Javascript-HTML chameleon files
• SVG-VML chameleon files
• Inline SVG
• iFrame squriting
• Script islands
• Embedded images
• Fragment IDs

I'll be posting a link to the slideshow notes from here. I'm pleased to say the nascent TiddlySlidy app has been a pleasure to dogfood it in.

[Image credits]

• Register all components that might listen to something.
• Register all events they might listen to.
• For each listener method among the components, automatically bind the event to it.

In code:

A component looks like:

And elsewhere in the code, the events it listens to get triggered through the normal jQuery custom events mechanism:

Part of this is based on what I said last night, which is (a) I'm keeping things simple - hence everything happens at startup and all the instances are singleton classes; (b) consequently, events are global, rather than being attached to any particular component.

Stepping back, what were the alternatives to this design:

• Components register themselves as listeners - this would be the purist OO answer, i.e. keeping objects autonomous. A perfectly cromulent solution, but a little more redundancy than it needs to be. If objects really do have consistently named listener methods, it's just as easy to handle registration automagically.

• The initialisation routine manually wires up components to events. It has a certain Python-like "explicit" feel to it, but again is quite pointless if we can instead do it automagically.

So where does the automagic model fall down? If we are doing things dynamically, it would get more complicated and would, for example, require objects to register upon their creation. So I think that's still okay. Another problem could be if a single method was listening to more than one event type, since this technique assumes it's one-to-one from event type to methods. But that's okay too - I actually had this problem and it was simply solved by getting both handlers to delegate to a third, common, handler:

I realised while working on TiddlySpace there's a lot to be said for dependency injection style patterns in Javascript, and it's not happening yet.

I'm very excited about the role, for reasons best explained in terms of a timeline for the web. I see the history of web technologies divided into three phases and I believe we're currently in the transition from the second to the third phase. Which is the starting context for this role.

Dark Ages (Web as a Black Art)

Rich web apps were hard work. Black art even. During this phase, I spent most of my time on server-side languages - Perl, PHP, Java/J2EE - and Javascript was a weird sideline. Taking an interest in the user experience, I always wanted to know more about this black art, since it's the web technologies that touch the user and have the most direct influence over their experience with any application. But what paid the bills in the late '90s and early noughties was form submissions and page refreshes. And most Javascript content was odd little ticker tape scripts you could download, not too much to learn from, and always difficult to achieve in one's spare time. I think this was the frustrating experience for many web developers: not enough time and hard work. I did get by and pick up a few tricks here and there, but things only took off when the A-word was unleashed ...

Ajax Era (Web as an Established Practice)

Everything changed five years ago, on February 18, 2005. Jesse James Garrett hopped in the shower, came up with the term "Ajax", and published his thoughts on this rising architectural pattern. Many people bristle at the notion that a simple term, for something people were already doing, can make such an impact. "BUT I already knew how to do that!" they cry. Good for them. But the fact is, Ajax allowed the whole developer community to rally around this style of application. Events, blogs, books, libraries, tools, the whole thing flourished. I got seriously interested, recorded a podcast explaining the topic, and started diving into all the existing applications, which ultimately led to the Ajax Patterns wiki. All those applications, and many featured in the book, were created in the Dark Ages by brilliant pioneers who had scant resources to learn from. Today, such applications can be created at exponentially faster rates. This is thanks to improved knowledge, improved libraries, and improved tools.

There are historical analogies to this era, e.g. the rapid rise of the automobile industry once all parts were in place. In that case, it was more a matter of discovering new physical and engineering principles, whereas with Ajax, it was a superficial act. The browsers were already there, with a killer feature like IE's XMLHttpRequest sitting largely unnoticed for five years. Few people had taken the time to really understand how they worked. It was the Ajax term to trigger the boom.

HTML5 Era (Web on an Improved Platform)

(I hesitate to call this the era of HTML5, as many things happening are outside HTML5, notably improvements to CSS and the core Javascript/ECMAscript language. But HTML5 is increasingly becoming a brand, much like Ajax in its heyday, a term that's familiar to anyone with a passing interest in technology.)

The starting point for this era is the success of open web technologies. While we continue to learn more each day, we have the basics in place today. We know how to harness HTML, CSS, Javascript to make powerful libraries and applications on the existing browsers. This is where the Ajax Era landed us. We have seen some genius hacks. In fact, we have seen MANY ingenius hacks. On-Demand Javascript and JSONP, for example, are completely fundamental to the way business is done on the web these days, and is utterly a hack. Full credit to those who came up with them, but these hacks can only go so far. They can increase programming complexity, impact on performance, and cause security threats for those not fully-versed in their capabilities. And that's just for the things we can do. The bigger problem is that we are heavily limited in our functionality on Ajax-Era technologies. We can't do rich graphics or video, for example. So the next stage is all about improving the underlying platform. It's not something an application programmer, however heroic, can do on their own. It's something that has to involve improvements from the platform providers, i.e. the browser manufacturers and others.

To draw a line in the sand, take IE6. Although it was created back in 2001, we could do far more with it in 2004 (e.g. Google Maps) than we could in 2001, and we can do far more with it in 2010 than we could in 2004. This is because of all the knowledge, libraries, and tools the Ajax Era has provided. However, we're in serious plateau mode now. We can continue to squeeze out 1-percenters, but the low-hanging fruit was plucked and digested a long time ago. The next stage has to be an improvement to the underlying platform, and that's what's going on today with modern web browsers.

Once you say "okay we're now going to build the next-gen web platform", you're not just going to add support for round corners. So there's been a truckload of effort going on, in HTML5 and beyond. Graphics in the form of canvas and SVG and WebGL and CSS3, media in the form of audio and video tags, semantic markup improvements, new form controls, offline storage, support for location-awareness. And much more.

We have the new platform and alongside it, we have the activity of understanding how to use the new platform. Not just understanding the parts, but the whole. How do you put all these things together in meaningful ways. Can we show custom-font text on a canvas? If so, how? And when does it make sense? And how to avoid performance problems? Or, to take another example, what kind of CSS transforms can we use to render videos? And since we can grab image data from the videos, what are some cool things we can do with that data? And all the while, where's the graceful degradation story here? How do these apps look in older browsers? Most of the talk so far has been on the capabilities of the platform, not patterns of usage.

All these new capabilities take us to the place we've been aiming for all along: true applications deluxe, not just "html++". Of course, there's plenty of room for both of these, but we're now in a place where we can really build true applications with all the capabilities of a traditional native experience. We're seeing it in a big way in mobile space. The new model is all about sandboxing, doing away with the filesystem, and explicit permissions. Exactly what the web's good for. They're not only a good fit technically, but they've become the ubiquitous lingua franca among the programming community. The technologies are familiar, as are the patterns of UI design and code composition. Those patterns will continue to evolve with HTML5 and associated technologies.

We're just scratching the surface here; there are exciting times ahead!

I'm not an official Googler yet, nor even a Noogler, as I've taken time off to chill, smell the roses, and pursue a few projects (like dusting off the homepage and ... watch this space. Actually, watch that space). I'm starting in about a month. And of course, even when I am official, this blog continues to be my own opinions, caveat emptor yadda.

The role covers EMEA and I'm still based in London. Despite not starting just yet, I'm looking forward to participating in tonight's Chrome/Chromium OS and HTML5 London event. See you there!

(I'm not the only one to announce a move to Google at this time. I'm looking forward to meeting and working with many of my talented future colleagues.)