This is the story about how a small startup company made a business critical decision that would prove to be of vital importance for the existence of the company.

Ezmo started out as a internal project inside of Fast Search & Transfer as a proof of concept of their mDisk technology. In February 2007 Fast decided that this project should be separated into a company on it’s own: Ezmo. When starting out as a separate company we needed to review where the state of the product and where we wanted to take it. It became obvious that we had tremendous problems with our client technology when it came to productivity and in terms of constraints in the web browser.
We wanted a more responsive and innovative user interface which could compete with the music players already on the desktop such as iTunes, WinAmp and Windows Media Player and a technology that enabled us to develop new features at a very rapid pace.

Responsiveness and development speed
Having worked with web based interfaces for almost ten years I knew that HTML and JavaScript (or “AJAX” as it’s called in the press) would never be able to give us both these things. The AJAX approach will always be constrained by the limitations and endless issues of compatibility which slows down development a lot and does not have a very good model for code reuse. In addition the response of HTML and JavaScript application tends to slow down as your scope expands. It became clear that Adobe and the Flex Framework would be the ideal choice for the new company. This was partly due to knowledge acquired at my previous position at Bekk Consulting and my former colleague Børre Wessel of Adobe Consulting. With it’s focus on rapid application development and the secure runtime environment of the Flash Player and Flex looked like the right choice for a start up company creating an online music player.

Taking the Flex-plunge
Deciding to use Flex was an obvious choice when looking at the technological aspects, but we had one problem: None of the developers had developed in Flex and most of them hadn’t heard of it until we decided to use it.
We had a development team consisting of: two Java back end developers with no experience of front end development, one Java developer with years of experience programming user interfaces and one interaction designer with some Flash development skills. Looking at this team you might think we had to undertake a long period of training and courses. Wrong, we dived right in and started porting our product onto Flex. How was this possible?

• Reuse existing Spring MVC application
• Tool support and ease of development in Flex

Our existing “AJAX” web application was a built on top of a Spring MVC application serving requests and passing back strings in the JSON format. When porting to Flex we where able to reuse most of our existing API and we where able to concentrate on programming the user interface in Flex.

We kick started our Flex development with a one day workshop where each developer picked a feature of the user interface to port to Flex. Prior to this session we ordered a couple of the Adobe Flex 2: Training from the source books, but it turned out we really did not need them as the number of resources on the web are good and easy to use. By focusing upon specific features which needed to be resolved we dived right into using the framework instead of spending a lot of time learning how the framework was built. This was a conscious decision as it would enable us to port the application quickly and focus upon learning the Flex framework as we went along.

After the one day kick off we just set off porting one feature at a time and after just about two weeks we had a fully functional Ezmo built in Flex deployed and ready! This was truly an amazing accomplishment for the team and it really showed us how easy it was to get started with Flex and how fast you can port an existing AJAX application to Flex.

In retrospect we see that it would have been beneficial to have had some more time learning the Flex framework prior to starting the port. I do not think we would have done it any faster that way, but it might have reduced the number of refactorings we have had to perform since on code which was not very well written because of lack of knowledge.

How was this possible?
We where able to develop with such speed because:

• Familiarity of the Flex Builder development environment
• Maturity of the Flex framework
• Ability to reuse existing technology and frameworks

Adobe Flex Builder

Adobe Flex Builder is built upon the Eclipse and this enabled our Java developers to work in a familiar environment. This made the transition easy for Java developers and saved us time as we did not have to learn a new tool to get started.

Reuse the existing continuous integration setup

In addition to the familiarity of Eclipse we where also enabled to reuse our entire build environment. We used Maven and Cruise Control for a continuous integration and with the help of the Israfil Maven plugin for Flex we where able to continue using this setup for building and releasing our new Flex application. This was a big help as we did not have to spend time on implementing or learning a new tool for building our application.

Utilize existing knowledge

Another very important factor was that we where able to reuse our existing Spring MVC and continue to allow our Java developers to work without changes because of the new user interface technology. Our AJAX application handled requests and sent back JSON-formated strings to the client. We used the XStream framework for the serializing of Java objects to JSON strings and we where able to reuse all the old code in Flex. Allowing us to continue to utilize the knowledge of our Java developers when developing a Flex application.

Being able to utilize our existing knowledge of the Spring framework and our knowledge of building scalable web services using Java a key success factor for Ezmo.

In summary
Working with web development for almost ten years I have full of enthusiasm tried to adopt new technology numerous times, only to be let down because the technology never could live up to the hype. Either because of lack of maturity in the technology, steep learning curve or lack of decent tool support. This was the case for DHTML back in the nineties and this story was continued when the AJAX-hype came along in the new millennium. HTML and Javascript based development has always suffered because of the terrible tool support and the lack of mature and robust frameworks. This is still the case after a few years of AJAX- and Javascript frameworks popping up like rabbits. Frameworks like Dojo Toolkit and Prototype still lack ease of development, tool support and a decent level of robustness and maturity.

Having worked with Flex for almost a year now I feel pretty confident when I say that this is by far the best technology for user interface development currently available. The maturity of Flex combined with the development tool makes it easy to learn the framework and helps you discover more and more of the framework as you go along.

Especially on the web there really is no real competitor for Flex in 2008. Silverlight and Java FX are all new frameworks which lacks maturity, development resources and no real developer community.
Adobe’s approach of making key components in the Flex echosystem Open Source has been a stroke of genius. Their latest decision of making Data Services available in the Blaze DS project should help accelerate the user adoption of Flex even more.

December 27th, 2007 | Flex, work