soledad penadés

I have been a bit disconnected from the Flash scene for a while and it's changed quite a lot! So I thought I may share with you my discoverings while I'm getting updated on the latest news.

There's this new thing called Flex. From what I understand, it will allow you to build entire interactive applications which run both on server and client side, using Flash for the interface.

Roughly, the interesting part here is that not all the processing is ran in the server, but also the client's computer is used to run the application. So, things such as updating graphs are made in the client side, with the data that the server sends you, allowing the server to save processing power and bandwidth.

The interface is specified with an XML based language and the application logic is written with ActionScript2; you can do it with the official Flex editor (even in WYSIWYG mode) or with your favourite IDE with custom XML language schemas support (one example: Eclipse). Then, you drop your code in the Flex server, and it will serve the appropiate interface data to the client depending on their actions.

This concept reminds me a lot to the first .net demonstrations I saw: you write code once and it will be served to the user through the .net server, which will determine the appropiate html and javascript stuff to be sent to the clients depending on their browser capabilities. The problem were the browsers' implementations and their support of javascript. Each time I asked the speakers about this, they never knew what to reply. Such an embarrassing question...

In that, Flex has already won the battle. As it uses the flash player to run in the client, they can guarantee a more or less known scenario and then the developers can build an application knowing for sure that it will always work, and there won't be weird implementations of one javascript method on certain browsers, etc.

It also reminds me to the AJAX approach: do not reload the whole page, send only the useful data, and redraw whatever is needed on the client side. The weak points of AJAX are still the different browsers' implementations, and rich media inabilities: graphics would be great, if all browsers implemented SVG properly. And unfortunately, browsers are unable to play sounds just by using html/javascript: as far as I know, when someone needs to play a sound nowadays, they end using a Flash object to play it (and yes, I'm ignoring the MIDI at all).

The advantage of AJAX versus Flex is that you don't need all the human and technical infrastructure that a Flex server requires. It is way cheaper to start building things with the Ajax philosophy (see ruby on rails), and honestly, most of the applications don't really need to have fancy 3d realtime graphics with motion blur and stereo surround sound.

Conclussion? Flex looks promising but it has its own application field, which can fulfill very appropiately. For relatively low-demanding requirements applications, there are other solutions which can work (and are working, indeed) pretty well.

Of course I might have misunderstood something. If there's something you feel is wrong please do not hesitate to leave a comment and I'll correct it.

Extra final bonus

Finally, if you are really curious and want to know some hidden and technical details about how the flash player is implemented -which is what at the end is going to affect everybody: you and your users- take a look at kaourantin.net. That's the blog of one of the engineers at Macromedia/Adobe developing the Flash player. He will get you informed about the changes they make and, from time to time, those little secrets that might explain certain flash oddities.