Thoughts on Flex and HTML5

It has now been a little over a week since Adobe revealed its plans for the mobile Flash player and the Flex SDK. Now that the dust has started to settle and some additional information has been made available, I wanted to give my candid impression of what these announcements mean.

I'll begin by stating the obvious: Adobe did a very poor job of coordinating and delivering these announcements. Anything I say at this point will simply be beating a dead horse. This was a PR disaster and one can only hope they learn something (ideally, many somethings) from sifting through the wreckage. I won't dwell any further on this since we have no control over what happened and I'm interested in looking at what these announcements mean going forward.

I suspect that the news that Adobe was stopping work on the mobile Flash player didn't actually surprise very many people. Further, I doubt many people actually care much. Yes, it's nice to be able to view Flash content on my Android tablet. And yes, its easy to forget that the existing 11.1 player will continue to work for a long time and allow people to keep viewing the vast majority of Flash content. But no one was building browser-based mobile Flash sites. Why? Because you still had to create a non-Flash version of it if you wanted to target all mobile devices. Once the sting of all the "Steve Jobs Won" gloating wears off, I believe most people will see the wisdom of this decision. Some people appear to have a problem with this choice, but no one I know really cared at all about this part of Adobe's recent announcements.

So now we move on to the other big news: Adobe announcing that the Flex SDK would become an Apache project and would go forward under non-Adobe governance. This took a lot of people by surprise, to put it mildly.

First off, let me say that I don't have an issue with the idea of Flex going fully open-source. Yes, Flex was already "open-source", but we all know it really wasn't. You could view the code, but Adobe still exerted complete control over what changes were made. Anyone who ever tried to submit a patch or improvement can attest to this. Those restrictions are now gone. I firmly believe that if this announcement had been made at MAX, rather than in the middle of this PR breakdown, the cheering from the audience would have brought the roof down.

I know a number of the people on the Spoon project, many of whom will probably be part of the group which will govern the ongoing work on the Flex SDK. They're all very bright people and I have little doubt that the SDK will actually see some nice benefits from this move. So from a purely technical standpoint, I think this can and probably will be a good thing.

However, regardless of what you think about the SDK move, another portion of Adobe's announcement overshadowed even this news. In a post that will probably live in infamy, some of the Flex management stated "In the long-term, we believe HTML5 will be the best technology for enterprise application development."

How Adobe failed to predict the resulting uproar I have no idea. But apparently they didn't. As a result, we saw an explosion of questions and concerns that essentially boiled down to: Is Adobe saying Flex is dead?

I'll admit I wondered this myself. Given this statement, what was I supposed to tell the clients to whom I've evangalized Flex? Is my investment in Flex now ashes? I was angry and confused. Then I tried to detach myself from my emotional reaction and consider the situation objectively. I want to share a few of my thoughts and conclusions about this.

First, one has to consider the harsh reality that Adobe never really figured out how to make any money on Flex. Their only real revenue came from Flash Builder, and it seems highly unlikely to me that sales of FB offset the money they've spent on Flex. And even that revenue is further reduced by the presence of competing tools like FlashDevelop and IntelliJ IDEA. Considered in this light, Adobe's decision to reduce the amount of resources it dedicates to Flex does make some sense, even if we don't necessarily like it. Offloading part of that cost onto the community is one way they can try to make those numbers even out.

Next, I'm not sure about everyone else, but I for one always believed that eventually we'd be able to build Flex-like apps in HTML. Some of this can be done already, but it is disjointed, using a mishmash of libraries, and painful. Building RIAs in JavaScript is agonizing compared to Flex and AS3. But that's slowly changing as the tools get better and the libraries become more refined and standardized. My guess is that in two or three years we'll start seeing real parity with Flex on both features and tooling. I knew this before Adobe's announcement, so does it really change much? Or did the announcement, as poorly as it was delivered, serve as a stark reminder that Flex is in some ways a bridge between now and this eventual HTML-based future?

I think this may be where some of the pain is coming from. No one wants to be told that the platform they're heavily invested in is probably going to be supplanted in the coming years. But can anyone really look at the current situation and draw another conclusion? Adobe seems to have two options here: keep pouring resources into Flex and delay the switchover a bit, or start changing direction and begin the task of improving HTML tooling from a RIA perspective. It's clear which way they've chosen to go.

So where does that leave us? Like many folks, I poked around the web last week just to get an idea of the current state of HTML RIA development. It wasn't pretty. I found dozens of libraries, frameworks, UI components, tools, and workarounds to mimic proper OO features in JavaScript. To put it bluntly, it's total chaos.

We're a long way from being able to drop Flex and start building enterprise RIAs in HTML. Which is fine with me. The projects I'm currently involved in are multi-year efforts built with Flex, and these aren't going away. I'll be building and maintaining apps with Flex for quite a while.

On the other hand, the writing seems to be on the wall. This isn't going to last forever. Developers who have been around the block a few times know it is always a bad idea to put all of your eggs in one basket. So I'll be keeping my eye on the HTML RIA space, trying things out as that platform coalesces. GWT looks interesting, especially paired with Groovy and SmartGWT. So does brunch.io. Trying out new technologies is one of the things I love about programming, and that's certainly not about to stop.

Will this change on the horizon amount to a career and knowledge "reset"? Is everything we've worked so hard to learn going to be thrown out the window? From my point of view, absolutely not. Looking around at the HTML/JS world, I see a lot of people trying to solve problems that we've already gone through. Solid OO design? Rich client models? Real-time messaging? Persistent client state? Separation of UI from client-side logic? Large-scale event-driven applications? Architecting and managing huge RIA codebases?

Sound familiar? They should, because they're probably problems you've already dealt with a number of times. The programming language might change, and the UI component APIs may shift, but these fundamental problems aren't going anywhere. And I think experienced Flex developers are going to be very well suited to helping businesses and clients solve those problems, both now and in the future. Even if the platform eventually shifts to HTML5. As they say, the only constant is change. And honestly, life would be pretty boring any other way.

Comments Comments (5) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 30741 Views

Spark Skins, Components, and Presentation Models

In the Flex 3.x world, I adopted the Presentation Model pattern and applied it just about everywhere. Separating the non-view logic made perfect sense, far better than the code-behind approach, and cleaned up the view components wonderfully.

Then Spark came along in Flex 4, and things have changed. The framework now has built-in support for separating the "view" (skin) from the "controller" (host component). As I've been using skinning more and more, I've come to wonder if or how the presentation model approach applies in the Spark skin world.

To try and answer that question, I created a fairly simple but non-trivial test application that creates the same views and behavior in three ways. I've heard each of these three ways mentioned at various times by various people, so I used them as the most commonly proposed options:

  • Supply a presentation model to both the skin and the host component, and let it act as a bridge between the two. In other words, the skin knows nothing about the host component, and the host component knows nothing about the skin. Create the PM as a self-contained set of methods and properties that can be applied to any relevant skin or host component. In essence, if the skin is the "view" and the component is the "controller", the PM is the "model" in this mini-MVC configuration.
  • Supply a presentation model to only the host component, and have the host component push state into the skin. In this case, the skin knows nothing about the host component, but the host component it tightly coupled to the skin.
  • Drop the presentation model approach completely. All behavior and properties are held in the host component, and the skin binds to host properties and invokes methods on the host. In this setup, the host knows nothing about the skin, but the skin is tightly coupled to the host.

After building all of these, there are pros and cons to each approach. And some definitely seem to have more pros or more cons than others. The one thing I tend to focus on is what kind of change and what kind of reuse each approach allows for. If you view the running test application, you'll see I've noted some thoughts on each in the sidebar. View source is also enabled, so if you want to look through the code or download it, feel free.

I'm very interested to hear other people's thoughts on this as well. So if you have an opinion on this, or any issues with how I've built any of these versions, by all means please comment below!

Comments Comments (18) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 7499 Views

Swiz Console 1.2, and an introduction to AOP in ActionScript

First just a quick note that I have updated the Swiz Console to version 1.2, which maintains parity with Swiz version 1.2. This update adds a tab to show views that have been processed with ViewAdded and ViewRemoved. As always, you can grab the swc or the source at my GitHub repository.

In other news, Chris Scott put up a blog entry on the Swiz site with an overview of aspect-oriented programming in AS3. One might speculate that this is a lead-in to some very cool stuff coming in the Swiz framework, if one were so inclined...;-)

Comments Comments (3) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 4852 Views

Fix for Using Subclipse Keyboard Shortcuts

Just a note for anyone who uses Subclipse within Eclipse to work with a Subversion repository. In the past, you could easily assign keyboard shortcuts within Eclipse for SVN update, commit, etc. In the newer builds of Eclipse I couldn't get this to work.

After searching Google, I found the answer in this Subclipse ticket. In order to get the shortcuts to work, you must go to Window > Customize Perspective, then under the Command Groups Availability tab, check the SVN option. It may require a restart of Eclipse, but the Subclipse keyboard shortcuts will now work.

Comments Comments (4) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 9715 Views

Swiz 1.0 Is Ready, and Updated Module and Chaining Demos

Today marks a big milestone in development of the Swiz framework for Flex and ActionScript: the team is proud to announce that version 1.0 has been released. This has been coming for a while, but we wanted to be sure we weren't rushing things and that the framework was really solid and ready for the 1.0 designation.

Download the final Swiz 1.0 distribution, which contains the swc, API docs, and source code. If you like, check out the release notes to see what's new since RC2. Finally, the wiki documentation has been updated to reflect the new changes.

To go along with the final 1.0 release, I've pushed some updated demo apps to the swiz-examples Github repository to show more of the chaining API and the inter-module communication options that Swiz brings to the table. If you'd rather see running code, I've got the Chaining Demo and Module Communication Demo applications live on my site. The view source option is enabled, so feel free to browse the code to see what's going on.

That's all for now. I hope folks find the examples helpful!

Comments Comments (6) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 7138 Views

More Entries