Welcome to Particletree!

When Chris, Kevin and Ryan approached Alex and I to develop Wufoo Unplugged, a desktop application to view Wufoo form data offline, we ended up choosing .NET because in addition to it offering the features we needed like multi-threading, file system access and pre-built Lucene libraries, it was also the technology that Alex and I were the most familiar with at the time. We weren’t officially part of the Wufoo Team then (Unplugged was basically our hiring interview) and so we weren’t asked to develop in an environment outside our comfort zone. As you can imagine, choosing a Windows-only solution left a number of Mac users feeling a bit left out. And so hoping to help out other developers thinking of creating their own desktop applications that will work on both PCs and Macs for their web services, I thought I’d do some research into the current state of cross-platform Rich Application Architectures and present my findings here.

Adobe AIR

Adobe AIR has made great strides in providing a cross-platform application architecture that sets a new benchmark for web developers dreaming about making things “better.” This environment provides a way for web developers who are comfortable developing in Flash, Flex or HTML to easily port their apps to a desktop environment. Like other frameworks that produce installable code it can install shortcuts on the desktop and interact with the file system. In the hands of someone familiar with creating Flash interfaces, AIR is capable of utilizing beautiful UIs that are not confined to the browser. AIR can also use SQLite as a database, which allows a developer to create a truly disconnected system. Additionally, using a specified coding model and an Adobe server product called LiveCycle, offline data synchronization can be handled automatically, freeing the developer the burden of writing this code alone.

One of Adobe Air’s strengths, the inclusion of an out-of-the-box synchronization, is ironically one of it’s downfalls. While this technology may save the developer loads of time, the configuration and maintenance of a J2EE-compliant server like jBoss (LiveCycle must run in a J2EE container) may prove to be overkill for a lot of organizations.

Another downside of Adobe AIR is the lack of true multi-threading. Plugins like Google Gears and Silverlight both expose multi-threading out of the box. The AIR framework, on the other hand, runs on a single thread. System threads to perform database operations are spawned separately, but once the data is returned, the processing of this data occurs on the same operating thread as the UI. While patterns exist to minimize the impact on the user, they may lack the sophistication veteran desktop programmers are used to working with in other environments.

One thing to keep in mind about developing an installable application like AIR, is the responsibilities that comes with the power of developing with AIR’s API, which is rather extensive. Just like any other application run from an installer, the user makes one choice at the beginning of the process to explicitly trust the application developer and the application. Because AIR has access to the file system, a developer with the wrong intentions could do great damage with it. While the AIR HTML security is designed to protect developers from writing applications that could be exploited by third parties, the up-front contract between the user and the AIR application still gives the developer a lot of opportunities to do evil. Check out Lucas Adamski’s article to get an understanding of the AIR security model.

Google Gears

Google Gears is a framework that adds powerful desktop functionality to the browser through a toolbar or browser plugin. Google Gears exposes three major components: LocalServer, which allows developers to cache and serve application resources (HTML, JavaScript, images, etc.) locally, Database to store data locally in a fully-searchable relational database powered by SQLite, and possibly the most important offering, the WorkerPool, which makes web applications more responsive by performing resource-intensive operations asynchronously.

From a security perspective, your users end up making a smaller commitment with Google Gears. Gears runs within the sandbox of the browser, storing data BLOBs and the SQLite DB within a protected area. Unlike an installed application, Gears does not have arbitrary access to the file system.

One promising feature in Google Gears is the BLOB API, which provides a way to reference binary data in web applications. Google’s Chris Prince explains in this video how the BLOB API can allow the developer to manipulate a memory stream that the browser can interact with to create an elegant solution for large file uploads.

Google Gears does find itself lacking in two areas: easy offline synchronization and advanced integration with the desktop. No framework is provided for synchronization like AIR. The architecture documentation explains to the developer how to check online status, but leaves the synchronization code up to the developer. Additionally, Gears is confined to the browser and so an application developer has no way to adjust the user experience outside the confines of the page. While the new Gears API has desktop shortcuts and Growl-like / Growl compatible notifications (depending on your OS), an application designer is very limited in creating the controlled experience you see in most desktop applications.

Microsoft Silverlight

Silverlight is a Rich Application Architecture designed by Microsoft meant to topple Flash as the leader in rich online content. Like Google Gears, it installs as a plugin and runs in all the major browsers. It offers slick vector graphics support, a sandboxed offline data storage component, and most importantly, access to a reduced version of the .NET runtime. Like all Microsoft development tools, the framework is steeped in Microsoft-specific buzzwords, but the concept looks compelling.

Silverlight consumes XAML documents that act as the UI layer instructing the instantiation of objects written in one of many of the languages supported by the .NET framework. This multi-language support is a key selling-point of Silverlight. It allows developers from an enterprise to contribute their pre-written libraries to a Silverlight project, provided they meet certain specs.

One major con to the development of a Silverlight project is the barrier to entry set up by the IDE. Unlike the other dev environment listed here, Microsoft stands alone in charging thousands of dollars for a single developer seat. For example, outfitting your single designer with Expression Blend, the creatives tool for working with XAML, and two of your developers with Visual Studio 2008 costs over $1700.

One other major concern is the install base and market penetration of Silverlight. Microsoft is pushing hard to power big-name events like the Demographic National Convention and the 2008 Olympics, where they reported that of the 50 million visitors nearly 50 percent of them had the Silverlight plugin installed. Compare that with the over 80 percent of browsers running Adobe’s Flash and it is easy to understand why website developers may be reluctant to serve a page that requires users to install another plugin. That said, with Silverlight 2.0 slated for a October 15th release date, you can be sure that Microsoft will be finding bigger venues to show off their shiny new plugin.

Further Reading

While this wasn’t a comprehensive review, I hope it’ll give you a nice jumping-off point for your own research. For more information, definitely check out the following articles:

• Silverlight Pros and Cons
• Adobe Air Pros and Cons
• Synchronization with LiveCycle
• Gears 0.4 Release
• Facebook uses Gears to Power Messaging