Topic: AJAX and Flash

On Dec 14th, 05

AJAX and Flash are different ways of making a web application more dynamic and interactive. When should a project use Flash, and when should it use AJAX? We look at the problem from 1)The capabilities of the technology (what you “can” do), 2)The affordances of the technology (What is “easy” to do), and 3)Business constraints of the technology (including recruiting issues, price, and vendor lock-in).

When considering Flash, we will include the capabilities of the FLEX development environment. When considering AJAX, we will discuss both proprietary and open-source AJAX APIs.

Cost to start using
AJAX is much easier to add incrementally to an existing web application. This is perhaps it’s single biggest advantage. No tools or software need to be purchased, existing web developer skillsets can often be leveraged, and a pilot project can be done in a few days or weeks. A Flash-based solution requires purchasing software, integrating disparate technologies, and possibly acquiring new skillsets. It is therefore a bigger commitment to try Flash relative to AJAX.

Download Size
DHTML pages typically end up being smaller (on average) than Flash SWF files or Java applets. However, this is at least partly a side-effect of the fact that many AJAX applications only use a small amount of dynamic behavior.

For equivalent full-blown applications (e.g. google maps vs. yahoo maps), file size is generally roughly dependent on functionality and the engineering prowess of the team building the application.

If your client may be using a slow internet connection, AJAX may be a better choice, since it can provide a lower “minimum footprint”.

Staffing
UI programming has been considered less “technical” than back-end coding since the shift to web-based software. This has historically meant that the people who knew the UI technology best tended to be the “creatives”, and the technical work on the front-end was of widely varying quality (top sins: copy-pasted javascript files for AJAX, graphics-heavy spaghetti-code for Flash).

However, this has changed big-time with the rise in popularity of AJAX. Very technical people are eager to learn AJAX, and there’s a groundswell of open-source APIs that they can use. It’s still hard to hire excellent JavaScript hackers, but there are plenty of bright people willing to devote themselves to learning AJAX now.

This is slightly less true for Flash/Flex. While FLEX is an appealing paradigm for developers (xml-based programming), it hasn’t quite lit a fire under developers the way AJAX has. As a result, hiring “experienced FLEX developers” is still quite difficult, and hiring bright engineers to learn FLEX still takes work.

Community and Momentum
AJAX came out of nowhere, and belongs to nobody. The fact that it’s become the hot technology du jour without any marketing budget speaks for itself. This is an approach to web development that has remarkable momentum, and a thriving community of practice.

The Macromedia developer community is thriving and cohesive, and the tools available to the community (meaning both FLEX and the Flash player) continue to improve at a rapid rate. But from a pure momentum perspective, it’s hard to beat the raw excitement coalescing around AJAX right now. This means we can expect rapid improvement in AJAX toolkits and rapid growth in the number of experienced AJAX developers over the next few years.

Politics and Vendor Lock-in
XMLHttpRequest (the foundation of AJAX) is an API that belongs to Microsoft and is not part of the JavaScript standard. Given that Microsoft is NOT interested in open web-based standards becoming more powerful, there is a risk that the next version of IE will somehow break XMLHttpRequest.

Our personal opinion is that Microsoft would be wary of “breaking the web” by changing XMLHttpRequest. It would certainly be a public-relations disaster for them if they tried. But given their past behavior, it’s still a possibility that cannot be discounted.

It goes without saying that if you develop with a proprietary AJAX toolkit, you are also getting locked into a relationship with that vendor. Open-source AJAX toolkits do not have this disadvantage: you are typically free to edit the code of the framework, and swapping one framework for another is an exercise in engineering but not an inherently difficult task.

On the flip side, if you do Flash development, your destiny is tied to the whims of Adobe, and whatever capabilities they add to their platform. You are locked into a proprietary programming world, with a single vendor providing your tools and the platform your code runs on.

If vendor lockin is important to you, then AJAX, using open-source tools, is the best approach. But be aware that you’re still dependent on the browser vendors, including Microsoft!

Availability of APIs and third-party Components
Along with the community of AJAX developers there has been an explosion in the number of AJAX APIs and frameworks. The best of these are quite good and getting better fast. These APIs do such things as :
abstract out the differences between different browser implementations of Javascript
add new functionality useful to developers
provide new UI components that developers can use. (note: this is still an area of weakness, but is rapidly being addressed. For example, the “higher level” widgets like data grids and tree views are not as mature as their flash counterparts. Lower-level widgets like “accordions” are easily available)

There is a thriving component marketplace in the Flash world as well. Most good components are proprietary, and are UI widgets of various kinds. APIs that provide other functionality are less available, but also less necessary (since the core capabilities of Flash are greater than the core capabilities of JavaScript).

IDEs and Rapid Application Development frameworks
Here the advantage goes to Flash. The FLEX IDE is superb, and allows developers to rapidly author data-entry-type applications. The equivalent for AJAX would be tools like Tibco IG or JackBe. Typically, these third-party tools require a commitment to their programming environment and toolset, which removes one of the biggest advantages of AJAX (the ability to add it incrementally to existing solutions with low initial commitment).

For a soup-to-nuts rich client development solution, there’s really nothing better than Flash, authored with FLEX.

Sockets (“pushing” data from the server to the client)

This capability is only needed for applications where real-time data is of vital importance: for example, trading applications, or multi-player online games. If this capability is required, than Flash is your only option. There is no equivalent in the DHTML world.

Integration with client microphone / webcam.

This capability (needed for communication applications) is similarly available only from Flash.

Integration with multimedia
One of the big advantages of Flash is that it natively supports streaming audio and video, something that obviously isn’t a part of DHTML. If you’re working with streaming multimedia, Flash is definitely the RIA platform to build your application on.

Graphical Capabilities
Flash is a vector-graphics based platform, which means that it can easily display arbitrary geometric shapes. AJAX relies on html/css for display, which means that it’s shapes are limited to rectangles. Any application that needs charting or graphing capabilities, or needs to display complex geometry, should be built on Flash rather than AJAX. This means that AJAX is a very poor choice for data visualization / executive dashboard type applications. It also means AJAX is a bad fit for (most) games.

Maintainable Code
Javascript development in general requires writing code that runs on different browsers (which implement Javascript differently). Writing this kind of code (in order to work on all browsers and degrade gracefully, everything is implemented two or three times) is annoying. Maintaining this kind of code is a real nightmare.

Fortunately, AJAX APIs that abstract away the differences between different browsers are becoming mature. Therefore, maintainable Javascript code is much easier to write than it was six months ago.

Flash coding (if it is done with FLEX) is very maintainable. If it is not done with FLEX, it is often quite difficult to maintain.

For both Flash and AJAX, if you use a reasonable engineering approach, you will have maintainable code. If you just start hacking, you will quickly create an unmaintainable, difficult to troubleshoot mess.

Cost
Flash and FLEX cost serious money, making them out of reach for many small startups. Proprietary AJAX frameworks are also quite expensive. The open-source world of AJAX + open source APIs provides lowest initial cost. Total cost of ownership, however, will vary widely with the type of project, skillsets of your developers, etc.

Conclusion
I hope this article provides a beginning framework for deciding whether to implement your next RIA in JavaScript or Flash. The two technologies have very different profiles, and in many ways compliment each other, so both are likely to be quite important to web developers for the conceivable future. so there should be room for both approaches. The important thing is to pick the right tool for the job.