Kranthi Kiran's

The battle for making riches out of RIA platforms is now really heating up between Adobe’s Flash/Flex platform and Microsoft’s Silverlight. This is an important area for the future of web applications, and is bound to give the winner a critical flow of developer bucks.
Up until now I’ve been an advocate of Flex through-and-through. This was partly, I admit, because I’ve always had the feeling that Silverlight has just been a copy of the Flex/Flash environment. But in the real world, it doesn’t matter so much who got there first, and it’s the current productivity and functionality benefits that count. And so it’s only come to dawn on me recently that there’s one big problem with Flex that Adobe has yet to face up to…if they can. And it’s potentially a killer.

The problem

At first the problem seems a like not such a big deal. In fact, for many RIAs out there today, it probably makes not once single bit of difference. But I think it really is a fairly vital feature that Microsoft offers out of the box, but Adobe has somehow managed to over-look. And I think it’s only because of the relative immaturity of RIAs, and the strong event focus of Adobe’s Flash platform that has caused it to be overlooked.
The problem comes down to one word: threading. In short, Silverlight has it, and Flash doesn’t. We’ll talk a bit about why Adobe haven’t provided this below, but first let’s examine why it’s an issue.

The scale of the problem

How important is multi-threading in the RIA space? Well, of course, that rather depends on what it is that you’re trying to build. As I have already said, I don’t think this is a problem for many of the RIAs out there today. On the other-hand, it certainly is for some. As RIA apps grow more complex and libraries become sophisticated and nested, it’s going to be more of a problem.

Synthesizers

Take the fantasic Noteflight. If you haven’t yet seen this app then you really need to check it out. This Flex RIA app lets you drag around musical notation to compose scores, which may then be played-back using a synth that overlays sounds loaded from .wav files on noteflights servers. It’s a fantastic app, and I’m pretty sure that tools like this will bring to many musicians what mp3s have brought to music listeners (i.e. mass, systematic theft of music, which has, somehow, to be properly monetized).
But ‘.wav’ files? What’s going on there? Surely nobody would notice if they noteflight used mp3s for thier sound samples, and wouldn’t the download time be a million times better? Well, as it turns out, noteflight.com used wav files because “an ActionScript3-based decoder is inevitably going to be slow (and consume development cycles too)“.
Now maybe I’m reading between the lines a little bit, but here is what I suspect is going on. If you do a method call to decode an mp3 file in ActionScript then it’s going to take quite a long time to complete. During that time, because Flash is single threaded, absolutely nothing can happen in the UI. Nothing. Progress indicators can’t update, mouse events can’t be processed, and the user will generally be left with an impression that the RIA is temporarily dead. This isn’t at all good.
For Silverlight, on the other hand, I believe it would be a doddle to spawn a worker process to sort this out, and meanwhile still remain responsive. Just like what you’d expect out of a modern-day platform.

Image processing

For a chronic example, look at the quick image resizer. This site is pretty nifty because it lets you resize a jpg, directly from your local filesystem, without once transferring an image between you and the RIA’s server.
But my-oh-my have you seen what happens when you resize a large image taken with a digital camera? Nothing….for a long while, and then…..your image. This simply won’t do.

Other apps

It’s not hard to extend this to a whole host of other applications that need threading. Doesn’t a word-processor need to spell check innocuously? Doesn’t any form of editor need to be able to process it’s content for saving, without blocking the UI? Is there any point in Flash Player 10 having support for audio processingPixelBender aside, which is kind of a cop out for certain flavours of processing, and besides, do most developers really want to have to code this stuff in a different language catered for mass parallel processing)?

Why is Flash like this?

The short answer to this is that Flash has grown organically and hasn’t always been intended for the sophisticated RIA applications that people are now starting to build with it. In fact, ActionScript was first created with much smaller ambitions: i.e. animated vector graphics. The Flash event model was ideal for this, queuing up messages for processing via a single thread. Now these original platform intentions have been hijacked to support the Flex libraries that enable such more complex embedded web content, but the underlying threading model didn’t change.
In contrast, Silverlight has been built from the ground up with more ambitious targets in mind: fully fledged applications.

How can the problem be solved?

Instead of moving in the direction of Silverlight, there are a few other steps that Flex developers can take to get around this problem. Unfortunately though, none of them are particuarly pleasant!

Splitting tasks up

One approach is to simply split up big processing tasks into small blocks so that other events can be processed between each block. If this is possible then it’s certainly an approach, albeit an awkward one. It goes without saying, however, that it is a complete pain to manually divide up sequential composition into Flash’s event model.

Spawning another VM

Another approach is to get all your work done in a completely seperate Flash virtual machine. Flash’s LocalConnection interface is probably the best way to communicate with such a seperate process. Despite again being an obvious pain to code, this method is also likely to be pretty slow at transferring large amounts of data between the VMs, and there are all sorts of synchronization problems when you cater for the user having the same app open in multiple browser windows etc.

Adobe extending the Flash Player and ActionScript

It should be possible for Adobe to cater for multi-threading in a single virtual machine, but it’s likely to be a lot of work for them. Obviously, many of the libraries (including the Flex ones) would need to be rewritten to add thread-safety. Events would still have to be processed one at a time by a single thread to maintain backwards compatibility, since existing apps will depend on this.
Adobe’s stance on this is a little disappointing, as Alex from Adobe explains on his very useful blog:
As we hear more from our users about the importance of threading, the higher its priority will be.
While it’s very nice that Adobe is taking our concerns into account, I can’t help thinking that this isn’t the best way for them to do business. Wouldn’t it be better if problems could be anticipated, rather than waiting until developers are upset about them? In this case, Microsoft seems to have managed this pretty well.