Posts filed under 'Articles'

RIA Development - Flex vs AJAX

Over the last year or so, progress in developing Rich Internet Applications (RIAs) has been at a dizzying pace. It seems as though there are 2 new AJAX/JavaScript frameworks coming out every day. Products like Macromedia Flex and Laszlo have been introduced and improved quickly. These advances are both exciting and somewhat confusing. It is easy to see how such technologies can aid us in our projects, but how do we evaluate them? Which route is the best?

At first glance, it may seem odd to compare Flex and AJAX. After all, Flex is a commercial product sold by Macromedia, and AJAX is not even a cohesive package, but is rather a collection of technologies. However, it is likely that you’ll find yourself comparing them to each other, as they accomplish roughly the same goal. In fact, the server-side code you’ll write will likely be quite similar regardless of which route you go - I’ve had demos setup that used the exact same business logic for both Flex and AJAX.

With that in mind, let’s compare these two technologies with regards to several factors. Bear in mind, these factors are not exhaustive, and there is no clear “winner” - the technology you choose will ultimately depend to a large degree on the project you are doing. However, this should help you better evaluate your needs.

1. Cost

At the current moment, AJAX appears to be a big winner in this category. With Flex 1.5, be prepared to shell out at least $15k, if not more. AJAX, being a collection of technologies, is free. With Flex 2.0 (to be released in early 2006), pricing becomes much less of an issue for Flex, even though it will be still fairly expensive -rumored to be in the sub-$1,000 per developer range.

Cost, however, can be deceiving. Flex has many advantages (discussed later) that, in my experience, save considerable development time. I don’t even dare to count the countless hours we frittered away on browser compatibility issues on AJAX projects - such issues are virtually non-existent with Flex. Given that developer time is rather expensive, it doesn’t take a lot of time savings to make up the cost of Flex. Granted, some of these issues are being minimized by the numerous AJAX frameworks coming out, but there are still few cohesive tools for creating AJAX apps.

The role cost plays in your decision will depend on how large your project is. A smaller project with small overall budget will probably favor AJAX, whereas a larger one may favor Flex.

2. Tools / Community / Documentation

Development tools for Flex have been very powerful, easy to use, and somewhat resource intensive. The current Alpha release plugin for Eclipse kills my machine (Athlon 64 3400+, 2 GB of RAM), but hopefully that will be resolved. I have yet to see any tools that aid much in the development of AJAX apps, but one would expect to see some soon.

The community surrounding AJAX is quite large, helpful, and very active. One can setup a simple AJAX app in under an hour, making it very easy to get involved with. On the other hand, the massive investment required by Flex has limited its community size, though the forums at Macromedia tend to be helpful.

Documentation for Flex is quite good, though to my knowledge, there is only one good book out about it - developing rich clients with macromedia flex, by Webster and McLeod. There is certainly more info out there about AJAX, though it is less organized, so you’ll have to work to find it. There are numerous books either out, or soon to be out, written on the topic. My personal favorite so far is AJAX in Action, from Manning.

3. Speed of Development

This factor is perhaps the most difficult one to judge, since it is prone to be largely subjective. I personally have found that Flex lends itself to much faster development, due to the excellent tools for it and the fact that you don’t spend time dealing with browser issues or tedious css/html issues. Many colleagues I’ve spoken with have found the same, though I suspect there are many who may have a different take on this issue.

Things like prototype.js, OpenRico, and others will probably help the AJAX framework out in this area, and I see the trend continuing. For now, however, I would argue that Flex development is much faster.

4. Compatibility with Current Platforms

It is rare that we get to redesign an entire app in one project. Much of what we do in web development is maintaining, enhancing, and slowly replacing old web-based applications. Therefore, it stands to reason that being able to selectively use a technology can be very positive. This is one area where I think AJAX really shines, as it is quite trivial to drop in an AJAX component here or there, without significantly altering the page. Flex can be used selectively like this, also, but it generally is much harder to pull off.

5. Production Quality

One of my favorite things about Flex is that its built-in styling makes it easy to create professional looking applications, even if you are graphically challenged like me. Flex applications generally feel smoother, in my experience, than AJAX applications do. You can create visually stunning AJAX apps, of course, but it takes much more work.

6. Conclusion

As you can see, both platforms are have their advantages and disadvantages. I’ll be using both of them for years to come, I’m sure, but as Flex 2 comes out I’ll probably be using more of it. As soon as Flex 2 becomes more stable, I’ll probably be conducting another test using it and some of the newer AJAX frameworks that have come out. It should be interesting to see the results.

I’m also anxious to hear what others have to say about it, especially within the context of your own projects.

2 comments February 13th, 2006

AJAX - Coupling Logic & Presentation Layers?

(This post is cross-posted on SpencerUresk.com)

Without a doubt, AJAX is one of the most popular new web technologies of 2005. Its rocketing popularity has led to numerous frameworks and projects to tie it in with existing frameworks. For example: ICEFaces (Java/JSF), MonoRail (.NET), and Ruby on Rails (Ruby). No doubt, tying AJAX components into an existing framework can save loads of time and cut down on the amount of code you have to write. What about coupling though?

I have taken the approach that AJAX is an entirely new layer, and have tried to keep its code separate from business logic. Why? By doing so, you can change any layer without messing up the other one (in theory!). Suppose your boss decides you need to move from a PHP solution to Java, or from .NET to Java - if you are using an AJAX framework that ties into .NET or PHP, you’ll be stuck rewriting a lot of presentation code that needn’t change.

Likewise, what if you have to move from AJAX to something like Macromedia Flex?
If your PHP, .NET, Java, Lisp, is spitting out generic XML, changing the presentation layer shouldn’t take a ton of work - indeed, I have switched presentation layers in exactly this manner, and did so with only minor changes to server-side code.

Or, perhaps you need to make your website more accessible, but you like the rich and interactive experience AJAX provides. If you are getting generic XML back from the server, you can just make a new presentation version that uses XSLT to create a simpler, more accessible website.

To me, AJAX presents an opportunity to have truly separate presentation and logic layers, but maybe I’m missing something. Am I?

Add comment February 13th, 2006


Calendar

August 2008
M T W T F S S
« Aug    
 123
45678910
11121314151617
18192021222324
25262728293031

Posts by Month

Posts by Category