I have finally gotten the chance to immerse myself in Flex code lately. I decided to do this series to capture my first hand experiences with Flex. Please share your feedback on the challenges and strengths I highlight. I would love to know if your experiences differ, or if you can fill in some of the gaps where I might be missing something. For those of you considering Adobe Flex, hopefully this will give you an accurate picture of building applications with Flex.

The compiler is currently my number one frustration with Flex development – it is quite SLOWWWWWWW…… To the point where I have been wondering if we are doing something wrong. I have done dozens of Google searches and only found mild relief.

In general, all compile operations seem quite slow. Our near deal breaking issue is around a SWC library we are building. Here are a few numbers to help quantify what we are seeing:

• 31 MXML source files
• 24 ActionScript source files
• 3 embedded images
• Building typically ranges from: 25-35 Seconds (On ThinkPad T60, Ubuntu, FlexBuilder 3, 2 GB RAM, Core Duo T5600)

We do have a couple of embedded resources, but I don’t see many options here since we do need these as part of our API. We also have the incremental and keep flags set:

-incremental=true –keep=true

It is nice to see Flash Player 10 beta is out with its performance improvements, but I don’t see much talk about addressing the MXMLC compiler performance. Are there plans to address this, or is there a workaround we are missing?

Click here to subscribe to my RSS feed and follow the rest of this series along.

I have finally gotten the chance to immerse myself in Flex code lately. I decided to do this series to capture my first hand experiences with Flex. Please share your feedback on the challenges and strengths I highlight. I would love to know if your experiences differ, or if you can fill in some of the gaps where I might be missing something. For those of you considering Adobe Flex, hopefully this will give you an accurate picture of building applications with Flex.

Let’s jump into the Overview. Overall, I still see Flex as a game changing technology – a total home run for application developers. Simply put, we have been able to do things that haven’t been possible with other technologies available to Java developers – certainly not for a comparable level of effort.

A key example of this is the user interface for the Gorilla eXecution Engine (GXE). The GXE is the product my company develops for executing and prototyping on top of UML models. The founding Gorillaz have built the user interface application on top of the core engine a number of times in different technologies (the most recent version in JSF). The Flex version we are currently developing comes with a number of benefits. First off, it is so much more compelling than the previous versions. More important though, Flex has enabled us to build truly extensible components that developers can use to build custom applications using the GXE engine, and there is already high quality tooling support for using these components. JSF is only now starting to get some decent tools – two years after the JSF version of GXE was developed, and JSF didn’t offer us a clean architecture to make our components truly extensible.

On the other hand, I have been a bit surprised by the overall maturity for a 3.0 release – with all of the activity around Flex I expected things to be a bit smoother. In our development, we have encountered a number of time consuming issues that seem to come down to framework and eco-system immaturity. The larger concern being the state of the eco-system, as Adobe is reliant on the community to thrust this forward. I do realize that this is the reality of working with an emerging technology and that it is one of the trade-offs. However, this shouldn’t be underestimated in terms of the time investment required to overcome these challenges. Things that are regarded as simple in more established technologies (e.g. in depth testing), like Java, can turn into a large time suck. I don’t see any of these issues as fatal for Flex development, and we have been able to overcome most of the challenges relatively quickly. However, like learning anything new, it is sometimes surprising where these issues arise. Also, it is important to weigh these challenges against all the things Flex makes easy that used to seem quite difficult.

Click here to subscribe to my RSS feed and follow the rest of this series along.

I am on a project where we are having to refactor our database frequently for any number of reasons. Hibernate has paid huge dividends in this area, as virtually our entire database is mapped into POJO’s. The net effect is that we get strong typing for a majority of our database interactions (we primarily navigate getter/setters & using Criteria queries), and thus refactoring is much-much easier. We do have a handful of SQL / HQL queries that have column / attribute names in strings – these are obviously much harder to refactor. Is there a another way for us to do update statements that modify a large number of rows, but still give us the strong typing we get by using our mapped POJO’s else where?

It seems that anytime you become an advocate for a given technology everyone wants to tell you about their experiences with it. This can of course be good and bad – depending on whether or not their experiences are positive or negative. I have been a fan of Adobe Flex since seeing a few demos of what one could build with it about a year and a half ago. At times in my career, I have acted in a technical sales role and often felt disappointed in the final results of the applications we were able to build using traditional Java web frameworks. They have gotten better in recent years, but are still constrained by the traditional browser based technologies. After a bit of playing with Flex, it was easy to see that this was a technology that would allow me to wow customers and users, and I began singing the praises of Flex.

At this point, the RIA landscape does have a number of other serious players (Silverlight, Curl, JavaFX, etc…). I have been primarily focusing on UI frameworks that have a client-side runtime. I am personally convinced that traditional browser technologies aren’t ideal for building rich applications. That doesn’t mean they aren’t ever appropriate, but if your deployment allows for dependence on a client-side runtime then using one of these platforms is ideal. My interest in all of the RIA platforms has been growing, but I have still been spending most of my time focused on Flex. A couple simple reasons have kept me on this path:

1. I have been doing some development for a consumer facing application, and deploying to the Flash Player is still the best option, as virtually everyone has the runtime.
2. We are doing some work at Gorilla Logic to enable our GXE product to provide rapid RIA prototyping support using a UML model as the backend (absolutely no code), and we are initially targeting Flex as it appears to have the largest developer community that could benefit from this tool.

Anyhow, these two applications have kept me busy with Flex as of late, and finally allowed me to really immerse myself in Flex code that I actually want to ship someday. Trying to build a “real” application always brings out the warts of a technology, which are usually easy to avoid when you are just looking at smaller portions of code. So, I thought it was time to do a series of posts capturing my first hand experiences with Flex – capturing both the strengths and challenges I have encountered with Flex.

I have two simple goals… First, I would like to capture an accurate picture of what Flex development currently looks like. Second, I am hoping the community will let me know where I am lost – where there might be a better way that I am missing…

• Here are the posts to come:
  • Life with Flex: Overview (Wednesday – 6/25)
  • Life with Flex: Compiler (Thursday – 6/26)
  • Life with Flex: Language (Friday – 6/27)
  • Life with Flex: Components (Monday – 6/30)
  • Life with Flex: Testing (Tuesday – 7/1)
  • Life with Flex: FlexBuilder IDE (Wednesday – 7/2)

Click here to subscribe to my RSS feed and follow along.

Stuart Stern, our fearless leader at Gorilla Logic, loves to share that “Everything you know is wrong” is not a value proposition. Usually highlighting mistakes he saw as an executive at Sun Microsystems – one example being the slightly delusional believe that everyone should be using Solaris on their desktop instead of Windows. Sun held onto this for years because Windows was insecure and clearly inferior to the Solaris platform. The problem for Sun was that people actually liked Windows no matter how much Sun told them they were wrong.

I think this sort of pitch is actually quite common, as technology vendors are trying to gain ground in highly competitive markets. A certain amount of comparing and contrasting is essential to help potential customers understand a vendors product and where it fits in the market, but sometimes it is just too much.

Last week, I did an interview with the folks at Curl (an RIA platform) for InfoQ.com. Following the comments on the post and reading more about their recent benchmarks, it seems that Curl has settled on a marketing strategy that boils down to telling people that everything about Flex is wrong and everything about Curl is great. This seems to be getting them some attention, but it misses the mark a bit for me. The industry as a whole can be mis-guided, but when it comes to Flex I don’t believe this is the case. Also, like most people I just don’t like being told that my firsthand experiences are not valid.

Honestly, Curl sounds like an excellent platform for building RIA’s. Although, I do have serious reservations about deployment with Curl, as virtually no one has the client-side runtime. One of the things I love about Flex is that deployment is greatly simplified, as most (all) users already have the runtime. I would encourage those building RIA’s for the corporate Intranet to evaluate Curl along with Flex – outside of that controlled environment I would stick with more widely adopted technologies.

I attended the Java Posse Roundup in Crested Butte last week. It was interesting to hear discussions on so many different topics. My favorites were ‘Why are Open Source People Such Weirdos?’ and ‘Overview of JEE.’

There were good conversations on RIA too, but generally a lot of agreement. Agreement is good, but doesn’t always make for interesting conversations. Although, it was interesting to hear a general excitement for what is now possible with the RIA platforms (Flex/AIR, JavaFX, Silverlight, and GWT), most everyone seems to have a wait and see attitude towards JavaFX.

You can read my InfoQ.com write-up on the conference and OpenSpace format at: http://www.infoq.com/news/2008/03/javaposse-roundup-2008.

For loving Flex so much, I have actually been skeptical about Adobe AIR. Over the last year, I have had a hard time understanding why moving applications from the Web to the Desktop mattered (it just didn’t seem that interesting). Then I had the chance to attend the Adobe Engage event two weeks ago, where they launched Adobe AIR with its 1.0 release. With the launch, they demonstrated a number of applications built using the AIR platform.

For me personally, it was one of those exciting, yet horrifying moments in life. It was horrifying because I started to understand how limited my personal development experience has been by only knowing a world where the browser/Internet exists. I have been in the software industry for 10 years – so for me it has always been about web based applications. There have only been two times in my career that have I been asked to build a non-web / desktop application, compared to dozens of requests for web UI’s.

So, even though it was a bit frightening to realize how limited my view of user interface development has been, it was exciting to begin to understand what is now possible as the web and the desktop blend with platforms like Adobe AIR. There were a number of cool applications / features demonstrated. One of the coolest applications was Sprout, for assembling content from anywhere.

Most all of the applications demonstrated were amazing, but much of my optimism and excitement comes from many of the subtle features in these applications enabled by the AIR platform. Seeing a Flex application in the browser communicating with an AIR application on the desktop is just cool, and will help us (developers) to implement features that improve user experience.

I am hanging out at Adobe Engage and my hockey team just brought back Peter Forsberg!!! Sweet!