There is an interesting discussion brewing over a couple of blogs. Part of it began when PPK wrote a rather strongly worded post titled “Apple is not evil. iPhone developers are stupid” where he accused some of the developers jumping into the whole native app for the iphone of not really considering the advantages of HTML5 and the powerful Safari browser on the iPhone for their applications.
Of course the iPhone native app camp had to respond and I am sure there are a few responses now online. The one I found that Aral Balkan linked to was by Faruk Ateş made some points around why the App Store in all its craziness is still worth the pain, but they centered around JavaScript performance (which I dont think is as bad esp for the apps that constitute 90% of the app store), HTML layout issues (which I dont agree with really) and making your application available at a place where users are actually looking for applications (some merit here).
Similar discussions also seem to be happening on the Google Chrome OS front (except that in that case there isnt a real option except web apps). For example, after Chrome’s public demo, in a followup Q and A session, Google’s Sergey Brin responded to a question saying that Chrome OS will not support any native application at all. Apple had encouraged developers to write web apps for the iPhone before the native app SDK was announced, but Sergey seemed to indicate that one reason may have been that Apple’s own native apps seemed to fragment user experience since the native apps felt different than the web ones.
I have to say I have yet to be convinced of the web-apps as native-apps concept. This week I have been halfway in the process of transitioning from one computer to another at work, and I was surprised at how much of my data is already on the cloud, between Google Docs, EverNote, DropBox, Flickr, etc, I had very little actual data to move across. That part of the dream is awesome. But using that data in apps is a different story. For one thing, there are very few guidelines for how web apps should look and work making the look and feel widely different and something that we learn from scrach on every new application. And network latency is often very painfully apparent, and I am not even talking for the data, its probable as you switch from one state of an app to another, you are looking at a blank screen for quite a few seconds before the UI gets loaded in, and then tries to load the data.
In a recent labweek project at CIM, we wrote a web application optimized for the iPhone for browsing Comcast On Demand content. The application, while functional, did not work nearly as elegantly as a native iPhone app especially on a device with spotty connectivity. I shudder to think what would happen if my Google NetBook was on a saturated network like AT&Ts right now. I imagine it would only take a few instances of “waiting…” messages to do something that traditionally was instantaneous to piss of a fair number of users (including me). Add to that html’s behavior of rendering incomplete content which then pops into the final look once images and icons get loaded, poor javascript animation (even if they are because of a poorly written piece of JavaScript code) would make the experience a far cry from what I have gotten used to in native applications like that on OSX or (even) Vista.
Perhaps part of the problem remains that we are trying to overload the browser metaphor. The web browser was written to browse documents, and HTML5 continues to move it in that direction. Maybe what is really needed is what I call an Application Frame, a browser that has no concept of a page. There are a number of features that this would need:
- A concept of state changes that dont involve the entire page to reload, nor rely on crazy JavaScript dom manipulation. Something that looks, for example, similar to Flex’s States metaphor. The application frame should automatically handle transitions by default unless the developer overrides that.
- The ability to proactively cache an entire application at the application startup, not just page 1 of a 5 page application
- Ability to add launch icons to the desktop/start menu (I think JNLP does this right now)
- Ability to override close action of the window that sends it into a windowless background process mode
- Notification APIs that allow the application that was set as a background process to be recalled into the window mode
- Ability to leverage system icons without having to package them into the app
I am sure there are more but these are the ones that come immediately to mind. Note that all this happens without an install process. The end user requests the application from a URI and the server can send back a new HTTP Header (something like Content-Type:Application/FrameContent) and then proceeds to send markup and javascript that defines the app UI. The Application Frame can even keep some browser behavior, like history of recently invoked applications, bookmarks, etc. Also the markup should include html and also higher order markup similar to widgets in, say, XUL or Flex.
Couple these with things that are now becoming part of HTML5 like built in databases and web workers and we could finally realize the dream of a “real” application sent to the end user by a webserver at the time of launch. But until that, I still think the web-application may not do it for me. Chrome may prove me wrong, but thats something time will tell.
Update: PPK has a new post up responding to the avalanche of passionate native app folk. Pretty fair points there.
. Personally this position also will help me grow in areas I have traditionally not dabbled in, be it more middleware/backend programming or business and finance. I am very thankful to CIM for enabling me to explore this direction.
. This blog will still be called Code Zen, and I will continue to release open source libraries (the 0.6 release of