The Adobe AIR 1.5 Cookbook from O’Reilly is now available for the Kindle. This book is great for anyone from beginning to advanced and covers Flex, Flash, and JavaScript/HTML AIR development:

The hands-on recipes in this cookbook help you solve a variety of tasks and scenarios often encountered when using Adobe AIR to build Rich Internet Applications for the desktop. Thoroughly vetted by Adobe’s AIR development team, Adobe AIR 1.5 Cookbook addresses fundamentals, best practices, and more. If you want to learn the nuances of Adobe AIR to build innovative applications, this is the book you’ve been waiting for.

As you might guess, I am a bit biased – but, I think this book is the best source of AIR recipes available today.

We need an open honest discussion about HTML5 and what it means for the web. Unfortunately, you aren’t going to get the truth from fanatics on either side, but instead we all need to examine all of the evidence and come to our own conclusions. I have spent a great deal of time analyzing the facts, and in the process I have made several observations.

DISCLAIMER: In full disclosure, I must mention that currently I am Flash Platform developer (primarily Flex/AIR). I also write a regular column for the Adobe NewsFlash newsletter. However, before I became a full-time Flash Platform developer, I was a traditional web developer who spent all day dealing with HTML, CSS, JavaScript, and PHP. I feel that I have an understanding of both sides of the discussion (but obviously am open to any input anyone has on the matter).

The Present

After much effort by many dedicated developers, HTML5 is just about ready for prime time. This process started about a decade ago, and gone through many iterations. Today, HTML5 is available and ready to go on a few platforms/browsers. However, not all browsers implement all of the standards, and some browsers haven’t even announced when they expect to have full HTML5 support⁶. In reality, version 3 of the iPhone OS is the only solid platform that has full HTML5 support (as well as some other fixed development platforms). What does this mean for developers? It means that HTML5 is still very much in the future (and not the present) for a majority of developers.

I was struck when reading Jeff Croft’s posting, Two Thousand and Twenty-Two, last September. It shed a lot of light on the frustration many developers are having with web standards as a whole. While, I haven’t even talked with Jeff directly, I have always been a fan of his work. After learning of the bleak timeline¹ put forth for full HTML 5 browser adoption, Jeff stated: “it ultimately doesn’t matter if HTML 5 is available next month, next year, or fifty years from now. Those of us who do real work in this industry know that the only thing that really matters is what specs and technologies are supported by the browsers real people use”.

Developers who have to build solutions for clients don’t care about the theoretical, they care about the reality. On that same vein, a solution is not a solution if it only applies to 10% of the target audience. It isn’t a solution if only applies to 90% (and leaves out 10%). Clients want sites/applications that work well for every member of the target audience – and they want it today. This brings me to my first observation:

Observation 1: Developers won’t be able to use HTML 5 in solutions they build for their clients (unless they are on a fixed-platform as described above) until at least 2014. For full HTML 5 functionality, this will be much later even than this.¹

Developers could look at creating solutions that leverage both HTML5 and the current HTML/JS model. However, this would mean that for a single solution a developer would have to create:

1. Browser detection to determine if the user is HTML5 capable
2. A full HTML 4.1/XHTML 1 application for current and older browsers:
1. Multiple CSS files (including hacks) to support IE6, IE7, Firefox 3, Safari 3
2. JavaScript that is compatible with all browsers listed above
3. A full HTML5 application (which will have little code overlap from the HTML 4.1 application)

For developers who already have to deal with the CSS and JavaScript craziness, this would just add another layer of complexity. In reality, HTML5 won’t be an option for traditional developers until 90%+ of the web is using an HTML5 capable browser. Keep in mind that most all sites still have to check for IE6 users, even though it was released eight years ago (2001).

The Truth About Plugins

At the heart of this discussion are the web plugings that we use today. Many articles⁵ have been written lately claiming that HTML5 will kill off traditional web plugins. In reality, this is far from the truth. Before I address that issue directly, we need to take a closer look at what is a web plugin.

When listing the common web plugins, most people realize that this includes the Adobe Flash Player, Microsoft Silverlight, and JavaFX. However, this also includes Google Gears, Google Native Client, the Google Earth plug-in, as well as the Google audio/video chat plug-in. In addition, to the Google plugins, there are countless plugins by other vendors. These plugins have been vilified due to the fact that they are ‘closed source’ projects. The truth is that the plugins have a rapid development cycle that leads to innovation. I am not saying that this can’t happen with an open source project, but I develop cutting-edge solutions for real clients. I can’t look to web standards for real innovation – only more of what has already been implemented:

Observation 2: Web standards will never innovate – they will only implement what plugins have already successfully included. This is due to the fact that the standards process is run by Microsoft, Google, Mozilla, and other companies that aren’t going to invest in implementing a feature unless it already has a proven place in development. The term standardization implies that you are taking something that already exists and creating a uniform process for implementing it.

In addition, many developers fail to acknowledge the role plugins have played in the HTML5 standard. This brings me to an observation:

Observation 3: Every new feature in HTML 5 (except maybe 2) were added because developers wanted functionality already available in a plugin. This includes offline cache (Google Gears), canvas (Flash Player), media playback (Flash Player and others), drag and drop (Flash Player and others), etc…³

At the recent forefront of this debate has been Google Wave, recently announced by Google at the Google IO Conference. This rich Internet application has been hailed as a great example of what web standards can do. However, virtually no one has commented on the fact that it requires a plugin to function. Yes, the example of what HTML5 can do requires Google Gears for some of its functionality. In reality, it is only for a small portion of the functionality (drag and drop), but it brings to light an important observation.

Observation 4: Google had the option to go through the standards process and try to add the drag and drop functionality before releasing Wave, but they decided that the user experience would suffer without the functionality. Instead, they chose to use the plugin to provide the best overall user experience.²

The truth is that plugins can ‘upgrade the web‘ in under a year. In reality, an idea can go through production, QA, released to users, and then pushed to 85%+ of the web within 16 months⁴. This is not the case with web standards:

Observation 5: Because of the major corporations and entities (as well as egos) that are involved, any major change (that requires browser creators to change functionality in a uniform manner), is guaranteed to take at least a decade from idea inception to actual implementation (across all browsers). The time required to allow for users of older browsers to upgrade, can add another 5+ years to the process.¹

If HTML5 were completely implemented by all major browsers today, and if all users had these upgraded browsers – the web plugins would take a serious beating from HTML5 (although even then – it wouldn’t kill them). In reality, HTML5 can’t even compete with the web plugins – because it is currently only viable on fixed-platform solutions (like the iPhone).

Quality vs. Standards

One of my major points of anger on this topic is that many developers are ignoring quality in pursuit of web standards. That is at the center of the video codec debate (and there are many examples of these types of issues around HTML5). Developers are choosing to evaluate solutions based on their relative openness rather than their actual functionality. What have the last five years taught us? We are finally entering an era where we understand that user experience is the key, and now some developers want to sacrifice quality for openness. This beings me to one of my most vehement observations:

Observation 6: Many open-source solutions are at the top of their respective field (Apache, MySQL, Linux, the Flex Framework, etc…). Inferior solutions (like the Ogg codecs) should not be tolerated just because they are ‘open’. If you want all browsers to implement a video codec, make one that is better than h.264. Developers should never sacrifice the user experience for the warm feeling they get when using ‘open’ solutions.

When a potential client looks at my body of work (or my company’s body of work) they will not care about web standards – they will care about the quality and functionality of the work. In addition, when a user uses my application, they won’t care about ‘openness’ but only about the overall functionality and user experience. As a developer and an employee of a company – I cannot recommend an inferior solution. I have to evaluate all solutions based on functionality to stay competitive. This means that in the future, HTML5 will be a solution that I consider if it provides better functionality – but, I will not choose it simply because it is open. It will be on equal footing with the other solutions that are available.

The Future

I hope that these overall observations have shed some light on this issue. The crux of the issue is this: fixed-platform developers can enjoy HTML5 now – and they should embrace it and start learning / working with it now. Traditional developers will have to wait around 5 years before it is a real option for them. In that time, we will probably have Flash Player 13, Silverlight 5, and JavaFX 3. Who knows what these versions will include – but, we can assume that the functionality they will include will probably be included in a future version of HTML.

¹ HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more
² Google Wave (video described Wave’s use of plugins)
³ HTML5 Versus Flash Versions
⁴ Adobe Flash Player Version Penetration
⁵ HTML 5: Could it kill Flash and Silverlight?, HTML 5: Could it kill Flash and Silverlight?
⁶ Compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies, Implementations in Web Browsers

In this while debate, I have made three observations about Apple that have shaped my perspective:

Observation #1 – Apple has proactively sought to eliminate any cross-platform development platform on the iPhone.

In many ways this is a good business more for them, but it highlights a bit of their true motives. Why aren’t projects like PhoneGap and the Flash Platform supported on the iPhone (even though both run perfectly fine on the device)? Very simple. Apple wants iPhone developers to be ‘locked into’ iPhone development. The last thing they want to see is one of their featured applications easily ported over to another platform (Windows Mobile, Android, Blackberry, Symbian, etc…).

Don’t believe me? Dion Almaer posted an article detailing Apple’s stance against PhoneGap last month on Ajaxian. He points out some specific verbage in the iPhone SDK agreement that outlines Apple’s position:

” An Application may not itself install or launch other executable code by any means, including without limitation through use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).”

While this isn’t entirely bad, it was clearly inserted to keep other platforms like PhoneGap and the Flash Player from encroaching on Apple’s native iPhone development platform.

Observation #2 – The Flash Player hasn’t been approved because it is a threat to Apple’s App Store Revenue.

Currently, there is no way to create rich dynamic applications outside of the iPhone SDK. With web applications, you are just limited to traditional HTML / JavaScript applications. The Flash Player would change this. For developers and users – that is a great thing. The iPhone SDK would still provide things like data storage, hardware access, etc… – but, applications not needing that level of integration could easily be deployed on the web. Many of the applications in the App Store could easily be Flash applications deployed through the web and not through the App Store – hence the problem. Apple’s totalitarian domination of the App Store gives them a conflict of interest when it comes to what is best for the user.

Observation #3 – Apple is only interested in helping Mac developers.

Again, this isn’t necessarily a bad thing, but don’t think that their motives are entirely pure. Could Apple have taken the cue from projects like PhoneGap or the new Palm Pre and allowed developers to write native applications (not web apps) in HTML / JavaScript, Python, Ruby, etc… Absolutely. Why don’t they? First, they want to promote (and increase) their developer base (who already is familiar with Objective-C, XCode, Interface Builder, Cocoa, etc…). Second, their developer base generates a great deal of revenue for Apple. Their developer programs run anywhere from $99 to $5,000 (and in some cases there are free accounts) per developer / company. They also sell a lot of conference passes / sets of training material each year. While this wouldn’t be eliminated with other languages, it would lessen the developer’s dependence on Apple if they could write applications in a language they are familiar with.

Conclusion

In reality, I am an iPhone owner and a member of the iPhone Developer Program. I think Apple has done a lot of things well with the iPhone, but as usual – they do an even better job of spinning the truth to suit their needs. The myth is that the Flash Player wasn’t on the iPhone because of performance issues and battery life – it just not true. Adobe has even publicly stated that they have a completely functioning version of the Flash Player ready to deploy on iPhones. Why is it not approved? In reality – because of Apple’s revenue stream.

Building ColdFusion Powered Flex and AIR Applications

ColdFusion 8 proved to be an ideal and powerful back end for Flex and AIR applications, and the next version of ColdFusion promises to go even further, improving integration and simplifying the building of data-centric AIR clients. In this session you’ll get hands-on experience with the planned Flex and AIR support in the next release of ColdFusion.

Hope to see you there!

I want to thank everyone that came out for Flash Camp Orlando! We had a great time – and a packed house. Greg Wilson gave us a look at the new Flash Builder and Catalyst betas as well as the Tour De Flex dashboard, Jason Madsen gave a great introduction to Flex, Carl Smith and Christian Saylor gave great presentations on UX and the relationship between developer/designer and user, Andrew Powell presented a great overview of BlazeDS, and Maxim Porges gave a great introduction to his upcoming Loom project that brings AOP to AS3.

I want to thank Universal Mind and Adobe for sponsoring this event! I also want to thank Andrew Powell (co-organizer of the event) and the rest of the Universal Mind team that volunteered time and effort to make this event happen.

Presentation and Code Samples

You can get my slides and code samples on the presentations page.

“app:/OTBAir.swf” “Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/526.9+ (KHTML, like Gecko) AdobeAIR/1.5.1″

So the application is named OTBAir – or something like that. If you know of this AIR application, please let me know ASAP. I am not upset – as I think this probably was an honest mistake, however, I am having to spend a lot of extra time blocking IP’s to prevent my server from getting bogged down with the requests.

Working with Data in AIR

My presentation on Working with Data in AIR covered the basics of working with the Encrypted Local Store, the file system, and the embedded SQLite database. We ran out of time and didn’t get to look at online/offline synchronization with LCDS, but we still covered a great deal in the presentation. You can download the slides below, and I will post code samples within the week.

Presentation Slides (PDF) – 1.2 MB

Directions to Titanic

This Friday is the much anticipated Flex Camp Miami. If you haven’t registered yet – that is fine. You have two options: go ahead and register at the site, or you can show up on Friday at the venue. This will be a great event, and I am really excited that we added Jeremy Grelle to the line-up (the architect behind the Spring / Blaze DS integration). This completes a great list of speakers covering a wide range of Flex/AIR topics. You can check out the full list here: Speaker / Topic List.

If you will be traveling into town, don’t forget the hotel discount code “FCM” at the Holiday Inn Coral Gables. We hope to see all of you there!

UPDATE: I can neither confirm or deny the predictions that Doug McCune made about Flex Camp Miami. You will just have to come and see.