Flex vs. Avalon

I've had Flex (Royal) on my machine for quite some time and was able to talk with the product team during the alphas. Now that Macromedia has publically announced a lot of details around MXML and Flex, I can finally say a few things that have been on my mind ever since my sneak peak of Royal.

A lot of people in the anti-MS camp will look at Flex and say, “hey, it's cross platform RIA solution, and XAML isn't”. Although it may be “platform independent“ to some degree, it suffers from a few of the same problems that the HTML model does as well as a few of its own.

First off, it is “server dependant.” Remember, you need to deploy the MXML file on the server in order to actually use it. When running offline, you are severly limited by the fact that you cannot call into a significant portion of your functionality, because it is all on the server. For example, lets say that you wanted to run an XML transform over some data and then output that as MXML or SVG and dynamically load that data into your interface. With Flex, this can be done ONLY when online, because all compilation takes place on the server. With Royal, such an operation is not going to kill you, because you have the full power of the platform when running in online and offline modes (there are a ton of other scenarios where the same limitation will come back to haunt you). Of course, this is why Macromedia calls Flex the “Presentation Tier“ solution, because it won't work for anything besides the presentation tier. The more client side logic your app contains, the less useful Flex will be.

Secondly, if you are an ISV, you should forget about creating Flex based applications any time soon. There is no way to deploy Flex apps apart from the server, so anyone who wants to run your app now has the additional cost / burden of the Flex server. Macromedia has not announced a free “Flex runtime” that you can distribute, so not only is your client base is going to be very small to begin with, but if you are not pricing your app at $50,000+ a pop, the server price may be a prohibitive factor when customers are looking into purchasing your app.

Thirdly, web service support in Flex is not nearly as good as what is already available in WSE. For one, security limitations in the Flash player will prevent you from making calls to any web services outside of your domain without using your server as a proxy server for the request (maybe not such a big deal right now, but that could mean a ton of extra traffic on your network if you have a lot of clients using your app...). Also, take a look at the list of Flex's supported standards and notice that the entire WS-* stack is missing (you get SOAP support, but that is about it... looks like Microsoft has Macromedia beat hands down on that front).

That said, Flex is definately a very cool product. However, if you think that it is going to eat into the market share of Avalon, you are dead wrong. Flex is for the next generation of browser based apps, Avalon is for the next generation of desktop apps.

[1] Macromedia Flex: the Presentation Tier Solution for Enterprise Rich Internet Applications. Nov 2003. http://www.macromedia.com/software/flex/whitepapers/pdf/flex_tech_wp.pdf

 

8 Comments

  • Thanks for the info, Jesse.



    The need for Flex Server does seem to be a hurdle in my mind, too. The proxy thing in Web Services has always seemed a burden, too. DO you know if they have plans to chnage that in the future?



    Nice to hear from someone who has used it.

  • I am not aware of any current plans by the Flex team in regard to this. But, this is a Flash Player issue, not a Flex issue, so the Flash Player team is really the one that needs to address it.

  • Not seen the product my self so I can only go of what Macromedia provide but .NET support in a future version (one can only assume 2 half 2004/1st quarter 2005) seems a little late. Surely a .NET and a Java release would be better? Maybe they want to aim at .NET 2.0, maybe wait to see how Avalon shapes up? but if they want to open Flex up to a .NET audience then surely they should start now?

  • I was also a bit underwhelmed by the .NET side of things. Not only are they releasing Java support significantly earlier, they've already announced Eclipse IDE integration (Partridge), but apparently VS.NET integration will be left to an even a later date (if it comes at all). Still, in their defense, they do have time constraints to work under. They probably created all their prototypes in java and so they would have had a head start there. In that case, finishing up .NET support probably just wasn't worth delaying the release of the product 4 months.

  • Jesse, true you can't access Flex data offline, but then wouldn't that be the case for your site right now - I can't access the content of this page unless I'm online or have saved a local copy - hmmm, this site is “server dependant” just like Flex...





    I think that this “server dependant” issue you're raising could easily be addressed by another MM product: Central, it's built on the Flash player but provides the developer a method of storing/caching data on the client side for offline access, I'd say that Flex & Central would be perfect partners.



    That said, I've had a think overnight...



    Flex & Avalon are separate products that meet different needs and we really shouldn't try to compare them as equals (pears v. apples), I totally agree with your last paragraph - Flex for the connected application (let's face it the browser is changing all sorts of other devices are now connected, the mobile market will in a short time be far bigger than the desktop). Avalon is for the desktop application, a traditional market that Microsoft still does very well at.

  • Yes, we will most definately see Flex and Central working together, but the current Flex incantation cannot function apart from the server, Central or not. Certainly Central could help if it includes an MXML parser and client side equivalents of the Flex Server, however, then you are bound to the Central environment and have to pay MM royalties for every copy of your product that you sell (not to mention that you would virtually eliminate the biggest benefit flash gives you, client independance, since Central only runs on OSX and Windows). I'd much rather take the MS approach via WinForms or Avalon and keep the profits and harness the full power of my desktop.

  • Well... on second thought, that isn't entirely accurate... you can compile MXML and run it apart from the server, but you do loose lots of abilities in offline mode.

  • Hi All,



    When Flash Remoting for J2EE and .NET is released, ive sent a mail to Macromedia Flash Remoting team stating that Mac. can come as a big player in Client Indipendent UI for Connected Internet Users as feature requests. Ive stated them below. But, its upto Mac. to make it done.



    1. Flex SDK should be free for developers like .NET SDK tobe installed for .NET / J2EE which can be used to develop and host Flex MXML applications



    2. Flex runtime can be distributed as like .NET runtime



    3. Macromedia can make money from Brady / Flex IDE



    4. Providing support for Java and C# tobe used as the optional language with MXML



    5. Supporting WebServices standards as like .NET and J2EE



    These will slowly make Flex/MXML as the default UI for all Enterprise Applications developed for Web in due course whether its developed in .NET / J2EE in future.



    Thanks and Regards,

    Sankar.B

    HCL Technologies,

    Chennai, India

Comments have been disabled for this content.