Adobe OnAir Seattle

I went to Adobe's OnAir Seattle yesterday, which was a really interesting event that I'd recommend attending if you have the time. Unfortunately, I had to leave before the end of the day, but here's a summary of the notes I took while I was there.

The Big Picture

Adobe's goal is to let web developers can use their existing skills (HTML, CSS, JavaScript, Flash, and Flex) to create desktop applications. AIR (formerly Apollo) provides cross-platform installation and application updates, a local database, and a variety of new APIs for managing local resources (local file access, controlling window chrome, drag and drop, etc). The Adobe guys were clear that this isn't about porting existing web sites onto the desktop -- assets and web services will obviously be re-used, but the emphasis was on not needing to learn new technologies (just a few new APIs).

Interesting Tidbits / Nerdy Technical Details

• Installation: Applications are installed via a single .air file. Installed applications can be removed just like normal applications (i.e. via Add/Remove Programs on Windows, or by throwing the application in the trash on the Mac). An express install (which can bootstrap the AIR runtime) and detection is also possible via Flash.
• Application Updates: AIR will provide support for automatic application update checking and upgrading.
• HTML Rendering: Adobe chose the WebKit HTML engine (used by Safari and Konqueror) specifically because of it's size and speed. Someone asked if they were considering moving to Firefox at some point, and they were clear that Firefox just couldn't meet their size requirements for mobile.This cements WebKit's position as the number three browser family (sorry Opera).
• PDF Support: Requires Adobe Reader 8.1 -- unlike HTML and Flash support, the Adobe Reader must be installed separately (I'm not sure what happens if it's not installed).
• HTML / Flash Integration: It looks like Adobe's done a good job integrating the two -- you can make script calls between the two, and there don't appear to be any visual differences between the technologies. I'm not sure about PDF though, I'll need to look into that.
• Script Engine: They're using the Tamarin JavaScript engine, which is far faster than what's in browsers today. They showed a demo of BuzzWord, a word-processing program built on Flash, which implements their own line layout and pagination APIs that run pretty fast thanks to the JS engine. The Mozilla team plans to use Tamarin in Firefox version 4.0.
• SQLite: This must be fairly new, because none of the talks or demos I saw were using the local database. Adobe did mention that they're working with Google to make sure they're API-compatible with Google Gears, which also uses SQLite.
• Native Windows: Can create native windows, or go chrome-less windows with transparency that give full-freedom (at the potential cost of consistency with other applications on that OS).
• Plugin Support: Currently only Flash and PDF can be embedded within HTML. Adobe says they're open to feedback as far as other plugins (QuickTime was requested by a member of the audience).
• SDK and Tools: Adobe already has mature tools with the Flash authoring environment, Flex builder, and Dreamweaver. They making sure to adding support for creating AIR packages (which are ZIP files) in their existing products, lowering the learning curve for developers. Command-line tools for packaging AIR files are provided as well.
• Adoption Rates: Adobe made sure to mention how quickly new versions of Flash get adopted by users -- they get 85% penetration within 9 months, which is quite impressive. Obviously, it's unclear if AIR could get this
• Linux Support: Planned in late 2008. Adobe says they've been waiting for the latest version of Flash for Linux before they port AIR.
• Random Notes: Built-in support for associating file types at install time, don't need admin rights to install AIR or AIR applications, events for regaining network connection, file dialogs, drag and drop support, use PNGs instead of dealing with .ico files, and Creative Commons licensing for the books.

MS vs. Adobe: My Take

This is the right strategic move for Adobe. They've managed to attack the biggest weaknesses of their chief competition, Microsoft's WPF, by being cross-platform and leveraging existing technologies already used by web developers. Using existing technologies also means there are many mature tools for both designers and developers coding in HTML/Flash, which is not the case with WPF. Adobe made a good choice not trying to boil the ocean with a lot of new technology.

Granted, WPF's target market is a bit different than AIR's (there are a large number of WinForms developers already using .NET technologies), but for web developers the learning curve and lack of cross-platform support made WPF a non-starter (notice how much more interest Silverlight has recieved in the community). Obviously, there are still many areas where WPF is superior (3D and document layout, to name two), but I think AIR's advantages more than make up for these drawbacks (from a web developer's point of view).

Although still in it's infancy, Silverlight will likely become the real competitor to AIR. Although it's feature-poor in comparison to Flash, Microsoft's clearly devoting a lot of resources to catching up quickly (notice the simultaneous release of 1.0 beta and 1.1 alpha -- which surely required a lot of testing resources). Silverlight plays nicely with HTML and JavaScript, provides good language support (including trendy languages like Ruby and Python), and has a very fast script runtime as well. It already lets you go into full-screen, I don't think adding more windowing APIs wouldn't be a stretch. I fully expect Microsoft to move in this direction.

Obvious Disclaimer: I do not work for Microsoft (although I used to). I don't have any inside information. Don't take blog posts too seriously, especially ones typed hurriedly on a hot day.