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

 

Published Monday, November 17, 2003 8:26 PM by Jesse Ezell

Comments

# Flex and MXML

Monday, November 17, 2003 11:00 AM by TrackBack

# re: Flex vs. Avalon

Monday, November 17, 2003 3:36 PM by Adam Kinney
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.

# re: Flex vs. Avalon

Monday, November 17, 2003 4:31 PM by Jesse Ezell
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.

# re: Flex vs. Avalon

Monday, November 17, 2003 4:52 PM by Andrew Stopford
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?

# re: Flex vs. Avalon

Monday, November 17, 2003 6:14 PM by Jesse Ezell
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.

# re: Flex vs. Avalon

Monday, November 17, 2003 6:54 PM by Andrew Muller
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.

# re: Flex vs. Avalon

Monday, November 17, 2003 8:17 PM by Jesse Ezell
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.

# re: Flex vs. Avalon

Monday, November 17, 2003 8:19 PM by Jesse Ezell
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.

# re: Flex vs. Avalon

Tuesday, November 18, 2003 8:57 AM by David Mendels
Hi,

Jesse, your final point is right where we are. We are not trying to position Flex as a head-to-head competitor or substitute good for XAML/Longhorn by any means. We think the design centers of the two products, target use cases, target users today are sufficiently differentiated that both can thrive. Both are very cool products.

At a high level, both technologies are trying to enable what Macromedia has been calling Rich Internet Application--apps that combine the responsiveness/interactivity of desktop apps with the ease of distribution of Web apps. But (simplifying) we are extending from Web apps up; and I see MSFT focused on desktop apps back. Further, our focus is the "reach web" where one can not ensure what platform (or what version of what platform) one's app will run on--Windows XP, 98, Longhorn--or Linux, Mac, PocketPC, Nokia. MSFT is driving to upgrade the worlds desktop Operating Systems and they are focused on Longhorn. That is valid, but it will take a long time and not meet everyone's needs.

Putting it in real world terms today at Macromedia: We are looking at building a new event management application for our web site. It has a public facing component (must be multi-browser/platform) and a behind the firewall component (should be cross-platform but we could restrict ourselves here) for administration. We want the rich data handling and UI that an RIA can provide. And we need it near term. We are building in Flex. However, one of our commercial product teams is looking at a new product that will not ship for several years--it is a desktop app (with a lot of internet connected functionality). It is a full, professional product, the needs to be extremely high performance (think Dreamweaver or Flash). We might use XAML in a case like this.

As for your points above that, about Flex being tethered to a server--that relates to the primary use cases we are designing for today--people who are building web presentation tier in JSP or ASP or CF but want the much richer data model and UI that is possible with a rich client app. However, for the long term, we are also looking at the disconnected case--it is just less of a focus for 1.0. So we are going to evolve the packaging, pricing and licensing models as we mature the technology for different use cases. Keep in mind that by the time Longhorn ships we will be on version 2 or 3 and will not just improve the product in a linear direction but broaden its focus in some ways as well.

You are also making some assumptions prematurely. We have not announced pricing or licensing options for ISVs. I can't do that now cause we aren't done -- but we are interested in feedback and what interest people have. This is a use case we think is important and valid, and ISVs embedding a version of the Royale engine that contains the pieces one needs at runtime is a configuration we need to plan for. We have some experience here--we already sell quite a bit of JRUN for ISVs who need an embedded J2EE server and provide an SDK that lets the ISV make the installation seamless and invisible to their customer. Of course, yes, we do charge money for software--that is our business--but the question will be for people to consider the value-add vs the cost rather than write off the option upfront.

Do keep the feedback coming.

Regards,
David
Macromedia

# re: Flex vs. Avalon

Monday, March 22, 2004 6:31 AM by Sankar.B
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

# Flex Vs Avalon

Wednesday, January 12, 2005 11:26 PM by TrackBack
There has been some interesting posts and very interesting debates about Flex Vs Avalon all over the web. Some of them which I came across recently are Dylan Greene's and Jesse Ezell's. One thing which you find common in all...

# html myspace backgrounds codes

Monday, September 17, 2007 7:46 AM by html myspace backgrounds codes

html myspace backgrounds codes

Leave a Comment

(required) 
(required) 
(optional)
(required)