I must admit that my session is going to be pretty awesome. While some people get to speak for an hour – or maybe an hour and a half, I will be speaking for 8 hours (with some breaks of course). I will be presenting on Building ColdFusion Powered Flex and AIR Applications (see all of the labs here). While the preconference sessions are an extra cost ($595), you get an entire day of training from some amazing developers. If you look around at rates for a one-day training, you will see that this is a huge bargain. Normal sessions give you a taste of certain functionality, but at a preconference lab you can really learn it and take it back to your job.

In my session you can be sure that I will be covering:

• Utilizing the new Data-Centric Development Features in Flash Builder 4 (with ColdFusion)
• Working with the Proxy ActionScript classes that were introduced in ColdFusion 9
• Configuring and Using the ColdFusion 9 AIR Offline Sync functionality
• Working with ColdFusion Builder and configuring it to work with your development server
• Defining a Complex Domain Model using the new Hibernate ORM Support in ColdFusion 9
• Using the Hibernate ORM and its ColdFusion Builder Extension to create remote CRUD services
• Creating new Script-style CFC’s (with annotations)

All in all – you won’t want to miss this session! If you have any questions – feel free to leave a comment!

After rummaging through the remoting config files, I discovered the issue. My bean CFC was using ColdFusion 9's new implicit getters/setters. To get this to work properly, you have to change a setting in the remoting config( specifically in services-config.xml):

By setting use-implicit-accessors to true, ColdFusion then uses the new implicit getters and setters in CF9 for your remoting calls. With that quick fix (and a restart) everything was working perfectly.

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

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.

So, what's with the referral program? Basically, you can win free books or even a copy of Flex Builder. To be eligible for the copy of Flex Builder, you need to refer at least 5 people to this event. For complete details on the referral program (and the new group rate at the hotel) see Brian Rinaldi's post on the topic.

See you in Miami.

I took some time off from speaking at conferences last year for the birth of our twins, but I will be speaking at several conferences this year. Flex Camp Miami is the first of those conferences. It is happening on March 6th in sunny Miami on the campus of the University of Miami (at the Hurricane 100 Room). Registration for this one day Flex/AIR training event is only $30.

So, who is this Flex Camp for? There will be a mix of introductory and advanced material (with most of it being advanced), so if you are working with Flex or AIR, this will be an event that you don't want to miss. The current speaker list is impressive and it includes Greg Wilson (Adobe), Brian Rinaldi (Universal Mind), Laura Arguello (AsFusion), Andrew Powell (Universal Mind), Maxim Porges (Highwinds), Brian LeGros (Highwinds), and me. There will be a few more speakers announced in the coming weeks. Current general topics range from frameworks, user experience, data handling, unit testing, Merapi, and also a great keynote from Adobe (see the agenda here).

I will be focusing on working with data in AIR. Here is my session description:

Working With Data in AIR: In this session, we will examine how AIR enables you to work with data including the embedded SQLite database, the Encrypted Local Store, the local file system, and AIR Data Sync with LiveCycle Data Services. We will cover both beginner and advanced topics. In addition to the overall topics, we will touch specifically on ORM options, storing binary data, and utilizing the encrypted database support.

Go ahead and register today, because a full day of Flex/AIR training from some of the best developers in the biz for only $30 is unbeatable (even if you have to fly in - it is still a great deal for a one day conference).

NOTE: Leave a comment if there is anything that you want me to address directly in this talk, or if you have questions that you would like to have answered.

I just published a full-length article over at InsideRIA that should help anyone that is interested in using deep-linking within a Flex application through the URLKit project. The article gives several examples (from simple to more complex), so even a person with no deep-linking experience should hopefully find it an easy read.

InsideRIA: Advanced Flex Deep Linking with URLKit

Presentation Slides (PDF)

An Interview with SlideRocket

The Flash and Flex Marriage