Flexing your apps

06 April 2007

There’s been a bit of chat recently around things like Flash vs. Ajax, the The Ajax/Flash continuum, and other similarly stirring topics. I’d been thinking a little bit about the same sort of stuff myself, and indeed I weighed in at Jeremy’s blog in a rather non-committal fashion (if that’s possible), throwing the best-tool-for-the-job line out a few times.

Of course I’m significantly hampered when trying to make a point in this argument by the fact that I have got pretty much bugger-all experience when it comes to Flash. So last weekend I decided to address that problem a little bit.

Why would you want Flash?

I think the crux of Jeremy’s argument is that if you’re going to define JavaScript as a base-level technology for your application, then you’re not using JavaScript for what it’s best at: progressive enhancement of structural, meaningful markup. If progressive enhancement is not part of the plan at any stage then perhaps you should reassess why you’re using JavaScript in the first place?

This all ends up pointing me towards Flex, a powerful application development solution for creating and delivering rich Internet applications. At work that’s what I do—I create rich (often overly rich) Internet applications which require JavaScript for you even to be let in. It’s this situation where it appears that Flex might be the better option, so that’s what I downloaded and filled my weekend with.

First impressions?

Now, I’m the kind of person that gets very excited when I’m learning new skills and technology, so I need to keep some perspective when talking about Flex. Firstly, I’m having a good time learning it, and I’m impressed with the speed and ease with which you can actually achieve things. It wasn’t too difficult to put together a very basic and crappy RSS reader within a few hours (although why it’s 255K is a little odd), and the feeling you get when you realise it’s going to work in every browser on every platform without you even having to think about it, or even test it, is nice—to put it mildly.

Secondly, I’d somehow picked up the false impression that I had to use Adobe’s own tools to write my code in. This isn’t the case. I can write the XML, CSS and ECMAScript (all these standards!) in Textmate or any other editor I want. The only piece of Adobe software I’m using (aside from Flash in the browser of course) is a small command line script that compiles my application into a .swf file.

It doesn’t really feel like you're entering a whole new world, and I got into some productive working habits quite quickly. There’s lots of concepts that those coming from browser based client-side development will be familiar with. It is of course all XML, CSS and ECMAScript, and the separation of content, style and behaviour is very much encouraged - if not enforced - within your applications code.

My problem with it?

I guess it sounds a bit naff; but it simply doesn’t excite me like the web does. In fact it doesn’t feel like part of the web at all. I want the semantics of HTML, the power and richness of microformats, and the potential for others to build on top of and extend my application with tools like Greasemonkey.

Flash by it’s compiled, closed nature doesn’t offer this and it’s hard to envisage a world where it ever will, despite Adobe’s moves to open it up with tools like Flex. I love that I can build Flash apps with standards like XML, CSS and ActionScript, and there’s no doubt that it takes away a lot of the pain of building web applications in the browser. It’s just that the end result never feels quite right to me.

However, now I’ve dived in a little I’m going to keep going. I’ve ordered The Complete Guide to Flex 2 and ActionScript 3.0, and I’m going to see what it takes to build the kind of applications I’m used to developing in JavaScript.

Most of all, I’ll now be able to join in the Flash vs. Ajax arguments with a little more professional integrity… or something.