A big concern of application developers is portability: if the same code can be made to run on different platforms, it enables the developer to reach a wider audience, and it eases maintenance and debugging. This portability is even more important for graphical applications because users are very sensitive to how applications look and feel. They expect applications to behave in a predictable, consistent manner across platforms.

It is not a surprise then, that there exist a [[http://www.atai.org/guitool/|large number of cross-platform GUI toolkits]]. So which one should you use for your next application? There’s really no good answer and you would probably end up using one of the many popular options. However, today there’s a whole new option you **must** consider: //the web browser//.

Consider this: Apple did //not// release any specialized SDK for the [[http://www.apple.com/iphone/internet/|iphone]]. Why? Well, the iphone runs a standard browser (Safari) and a standard OS (OS X), so Apple will just leverage the huge developer community around Dashboard widgets to catapult applications for iphone (some coverage [[http://www.niallkennedy.com/blog/archives/2007/06/iphone-widgets.html|here]] and [[http://www.37signals.com/svn/posts/459-iphone-sdk-its-called-safari|here]]).

Another growing trend is online applications. There is already so much to read out there on this topic that I’ll just point out some of the better known examples: we all use [[http://mail.google.com|gmail]], [[http://docs.google.com|online spread sheets and word processing]], [[http://zoho.com|Zoho]] has an entire productivity suite for you, both [[http://www.zimbra.com/|Zimbra]] and [[http://mail.yahoo.com|Yahoo! Mail]] replicate an Outlook like interface in your web browser and I could on and on and on — you get the point.

The bottomline is that the browser has already become a very flexible and feature rich platform for building applications. There are [[http://edevil.wordpress.com/2005/11/14/javascript-libraries-roundup/|several]] comprehensive Javascript libraries out there, making it easy for developers to build rich, interactive user interfaces that rival (and often beat) their desktop counter parts. Further more, with technology like [[http://gears.google.com/|Google Gears]], it is now possible to keep running applications even when the user goes offline. Of course, Javascript is not the only language you can use. Both Adobe and Microsoft are entering this space in a big way with Adobe’s [[http://www.adobe.com/products/flex/|Flex]] and Microsoft’s [[http://silverlight.net/|Silverlight]].

Clearly the trend is that your browser can do a lot more than it used to, and that you will continue to use the browser even when you are not online. As this notion of browser and “surfing the web” or “being online” gets decoupled further, I think we will start seeing stripped down versions of browser runtimes that are optimized for application specific usage.

For instance, say the OS ships with a minimal browser runtime. Then, I download a Google Reader application which is essentially a small wrapper around the runtime that enables some additional functionality, extensions/widgets etc, as well as the stub that allows it to work offline. In a similar manner, Zimbra/Yahoo could package their mail application. This packaging is just a nice side effect — you would always be able to use these applications in your standard browser mode anyways.

But the best part in building for a browser is this: Firefox //already// looks and feels the same across platforms, and so does Safari. So why do you need to bother with yet another cross platform toolkit? Building for a browser not only gives your cross platform compatibility and portability, but opens the door to easily adding networked feature to your application. For instance, it would be trivial to have your application send back some usage/crash data to you, or to add social networking features to your applications, or to re-use existing widgets/extensions to improve the user experience.