I’ve had this draft sitting around for a while now, but prompted by Tim’s and Ben’s posts on HTML5 and the web as pertains rich applications and such, herewith some thoughts based on fighting with HTML5 Apps in the context of rePublish.
Cross Domain, Already
The largest barrier to HTML5 as a viable platform is cross-domain AJAX. Full stop. If you think I’m wrong or just whining and that I should just use JSONP or CORS, go try building any of the following without relying upon a server-side component and all the privacy, cost, and maintenance issues that such a beast entails:
- A .doc editor.
- An ePub reader.
- An image editor.
- A multi-protocol IM client.
- A P2P client.
If we’re going to build applications that read documents in HTML5, we need cross-domain requests. JSONP doesn’t cut it. CORS doesn’t cut it. Downloadable applications don’t need CORS headers in order to make HTML requests; why should installable HTML5 Apps be subject to this crippling restriction, based fundamentally in a stupid policy decision around cookies?
With the advent of the FileAPI, client-side development can finally read local files (though not directories or recursive paths). So there’s that.
Web Protocol Handlers
Once upon a time, when faced with a link like this one: mailto:email@example.com, the operating system or browser would do the right thing, which is to look up the application that the user has chosen to handle mailto URIs in a system registry, launch it, and create a new message addressed to firstname.lastname@example.org.
Email links don’t work for me across all the browsers I use, because there aren’t hooks to tell browsers (or the OS) to use a web URL as the handler instead of some application in my path. This is stupid, and based entirely in technology decisions made over twenty years ago. Thinking about the future, for example, wouldn’t it be awesome if Delicious or Digg could register a ”share” protocol handler, so that instead of having a horrible NASCAR mess of social sharing links, we could have our browser fill in the blanks with the site we use — “share this using your preferred tool” rather than “share this with any of these tools you’ve never heard of.”
… and Content-Type Handlers
Likewise, when clicking a link like this one: http://example.com/zipfile.zip, the browser would check the Content-Type header for a mime-type (in this case application/zip), look up the application designated to handle application/zip files, and launch it with the file in question as an argument.
There’s a W3C / WhatWG proposal based on a feature added in Firefox 3 to add both protocol and content-type handlers that can be fielded by HTML5 Apps, but all you get at the other end is a URL - there’s explicitly no way for your HTML5 app to do anything with the URL, because of cross domain restrictions.
Sure, you can refer your app to your server component or build a “native app” for every OS to which you’d like to deploy, but there are a whole bunch of issues that arise if you’re not trying to lay your dirty hands on every bit of your users’ UGC. Privacy, performance, UX, policy, bandwidth, costs; these are all non-trivial factors that are much easier to deal with in the context of client-side applications than they are in the context of a vendor-owned website.
So, Browser Developers
But, we need tools to build these things. CSS Animations are great, Canvas is amazing, but how about some low-level tools? Mobile Safari already has the “add to home screen” button, why not add something similar to the desktop browsers? “Install this [web] application [with extra permissions]” would be an amazing boost for the web, fill in missing pieces in Tim O’Reilly’s Internet Operating System, and give us some real alternatives to the multifarious app stores that lurk in every corner.
tl;dr: HTML5 Apps need cross-domain requests, protocol handlers and content-type handlers in order to be first-class citizens. Browser developers can and should make this happen, sooner than later.