Editor's note: Dan Kantor is the CEO behind the awesome ExtensionFM project. It really pushes the boundaries on what the Web can do, so I asked Dan to give us a mini case study on the project. What follows is his words on the matter. Thanks for taking the time Dan!
Dion recently posted about the march to a more client-centric web. The post hit home with me as the founder of a web-based application that is as much 'app-like' as it is 'web-like'. The promise of the web, and HTML5 in particular, is that we will finally reach the write-once, run-anywhere dream we have all been in search of that neither Java nor Flash could fully deliver. Dion poses this question (and answer) towards the end of the post - 'As a developer, do you want to port experiences between incredibly varied platforms such as Web, iPhone, Android, WinPho 7, RIM, Kindle SDK, [insert many others!]? No.'. I don't think many developers would argue with Dion's answer. The real question is - 'Are we there yet?'
My company is developing a client-centric web-based music player that cuts no corners in its attempt to look, feel and run like a native application. We threw progressive enhancement out the door, pushed the pedal to the HTML5 metal and created something that most people would be hard-pressed to believe is not a native application if they didn't already see it running inside the browser. However, there is a catch. Our application only runs inside Chrome. This was of course by design. We built it as a Chrome extension. We didn't choose to do this because we wanted to restrict it to Chrome. We did this because a large part of the functionality of our application needs the extra APIs and permissions an extension gives you. A nice side-effect of that is we know 100% of our users are using an HTML5 capable browser. Chrome extensions are 100% HTML(5), CSS(3) and Javascript. Extensions provide extra Javascript APIs that give you access to functionality that you otherwise would not have running as a website such as removing security restrictions on cross-domain xhr and requiring permission to display desktop notifications. Of the thousands of lines of code in our extension, only 5% of it is Chrome specific. In theory, this should make porting to other browsers and OS's easy. Let's see what it looks like in practice.
A few months ago, we decided to see what our application would look like on the iPad. After just four hours, we had a working prototype of our music player that looked and felt native but more importantly looked and felt exactly like our Chrome extension. This was possible because Chrome and Safari share the same rendering engine - Webkit. Mobile Safari has already implemented many of the HTML5 features we needed such as HTML5 Audio, Web Database and Local Storage and many of the CSS3 features we needed such as Background Gradients, Rounded Corners and Box-Shadows. We were able to re-use most of our Javascript code and since we used a lot of CSS in place of images, we were able to resize elements with ease. But a prototype is just a prototype. Could our web-application actually be a viable shipping product on the iPad?
At this point, the answer is no. Mobile Safari has two quirks that seriously hamper its ability to act as a web platform. The first is it's lack of fixed positioning. If there was one feature that defined native applications vs. web applications it would be that native applications almost always frame content with a top and bottom layer of buttons or displays. Think about iPhone apps. Almost every one of them (minus games) has a navigation layer on top and a series of buttons on the bottom. To pull this off as a web-application, you need fixed positioning. Unfortunately, Mobile Safari (as well as Android's browser) do not provide this feature. There are many hacks to emulate it though. Apple has even developed a Javascript/CSS framework to get around this themselves. For our iPad web-app, we used a library called TouchScroll that uses Javascript and CSS animations to emulate scrolling. Overall, the lack of fixed positioning is not a game-ender, as hacks are available, but it certainly adds a layer of complexity to building a client-centric web-app that will make many developers' lives more difficult. The next quirk may just be a game-ender. Mobile Safari on the iPhone and iPad has an annoying ability to refresh windows once you open up a few. So say you have a few windows open including our music player. The music player is not the active window however. When you click back on it to make it active, it refreshes. I'm not sure why this happens although my guess is it has something to do with memory management. Either way, most apps (especially music or video ones) cannot be taken seriously if the application is constantly refreshing. Sure, in theory applications could maintain their state between refreshes. But in practice, this never works quite as well as we'd like it to. Of course, music stopping and starting constantly will be a game-ender. I am hoping that the iPhone 4 with its 512MB RAM does not have this issue. Android does not seem to suffer from this but Android does not support HTML5 Audio or Video so it certainly has drawbacks of its own.
A couple of weeks ago, Safari 5 was introduced with support for extensions. We spent a few hours reading the documentation to see what it would take to port our extension from Chrome to Safari. Unlike Firefox, where extensions are a bit more than just HTML/CSS/JS and support for HTML5 features are lagging, Safari extensions are theoretically similar to Chrome. Other than different Javascript APIs, the functionality offered is almost exactly the same. We determined that it would not be too difficult to port. Of course, business decisions are not always just about technology, so we are waiting a bit before we do just that. It will however, be very interesting to see if Apple brings extension support to Mobile Safari on iOS.
Coming back to Dion's original post, it seems like we are closer to write-once, run-anywhere using client-centric web-based applications than we have ever been. With a few modifications, we can basically re-use 80% of our code to deploy on the desktop and mobile. Unfortunately, not all browsers are there yet though. The issues I listed above seem like minor ones that can be fixed easily however. It would not surprise me if in the second half of 2010, Mobile Safari fixes the refreshing issue and Android adds support for HTML5 Audio/Video. As more frameworks are released that deal with the fixed positioning problem, I expect more developers to look seriously at the web as their platform of choice for deploying mobile applications. As for the desktop, Firefox 4 and IE9 should finally add the HTML5 and CSS3 feature support that Chrome and Safari have had for a while now. Of course, not all users will have the latest and greatest browser. Progressive enhancement will be the only way to support those users. But by pushing the envelope of what's possible, we will hopefully push those users towards upgrading to a modern browser.
For a 60 second run through of ExtensionFM, check out the video below:
