Andrew Stopford's Weblog

According to Dave Mendels, "one area we are late on has been the native .NET version of Flex. We've had an early beta in the labs for a long time but have not gotten it out the door yet." So, Macromedia is figuring .NET into their plans, but Flex seems to be more of a competitor to ASPX / ASP.NET than it is to XAML / Avalon, as the SWFs it generates can't stand on their own without giving up a good chunk of important functionality. To me, it seems that Macromedia has a lot of great ideas that fail due to poor execution. They are fighting the wrong battle. They don't need to make a better version of ASPX, they need to make a more accessible version of XAML. They missed the chance to beat Microsoft to the punch when they failed to deliver that with Flex and version 7 of the Flash player.

Hi,

MXML and XAML are similar approaches to solving similar problems--both are declaritive mark-up languages for describing front end UI and data binding, and work together with procedural languages for client logic (ActionScript/ECMAScript with MXMXL, C# or other .NET languages with XAML). MXML is not designed to compete with ASP (or JSP or CFML or PHP or Ruby) but to integrated with it and solve the client tier problem.

Regards,
David

I wasn't claiming that MXML competes with ASP.NET, I was claiming that it competes with ASPX/ASP.NET. Obviously MXML can't compete directly with ASP.NET, since ASP.NET is much bigger than MXML and a huge chunk of ASP.NET deals with server side concerns, not client side concerns. An Avalon/XAML solution would also integrate with ASP.NET or Java or some other server technology, but not in the same fashion as an ASPX or MXML solution.

MXML and XAML both do a nice job of solving the problem of declaratively building UIs and handling databinding concerns, as does ASPX. However, XAML/Avalon does it without the added server side dependancies of Flex or ASPX. XAML/Avalon retains 100% of its power when you are running in a disconnected mode. Flex does not. ASPX does not. The very fact that you need to integrate with PHP / ASP / JSP to solve the "client tier problem" is the most disturbing fact. In this way, Flex is more similar to an AJAX solution than it is to a XAML/Avalon solution. I don't think this is something that would be all that hard to solve. However, until that server side dependancy is removed entirely, Flex applications aren't quite ready to compete against a full smart client application developed with competing client side technlogies (whether that be Java, .NET, Win32, etc.). It will just be an in-between solution like AJAX. The applications will be better than traditional HTML pages for sure, but not quite ready to fully function in occasionally connected environments, to use the Macromedia terminology. In any case, that is why I say that the current iteration of Flex really competes against ASPX as the client tier technology, not XAML.

Hi,

Thanks for your comments Jesse and David. I agree with Jesse that MXML competes with ASPX and that Avalon as a client side technology is a different bread to Flex as a server side model.

It's worth noting that Flex has a command line compiler but I think thats just a way of invoking the server. Laszlo may be following this model or may be up to something different (anyone from the Laszlo team listening?)

I would say that the issue I can see is that .NET in an enterprise sense is not (as much as I can tell) on the radar. When we consider that Avalon will be tightly coupled to the CLI (and all the languages that support the CLI) as well as Indigo it has a real place in the enterprise heart and mind of .NET. I am not at all sure that AS will convince .NET developers that Flex is worth considering when they can use the same language they use everyday (be it C# or VB.NET) with Avalon. While AS may be in a syntax sense like C# its still a new language and how much more productive will a developer be when they are coding in a language they now, not one they have to learn (not to mention the costs of that).

> different bread to Flex as a server side model.

Seems to be a lot of conclusions based on Flex being a server side model.

However, as I posted here:

http://weblogs.macromedia.com/mesh/archives/2005/08/will_zorn_requi.cfm#more

we are working to expand the reach of the Flex Framework, and Zorn will be able to compile applications based on that Framework, and not have any restrictions on how those compiled applications are distributed.

Hope that adds some more context...

mike chambers

mesh@macromedia.com

Thanks for the post Mike, as I under this the Flex Framework can allow SWF's to be genearted using Zorn and can stand alone from the server. However the server is needed for more enterprise features (and Jesse states that this will mean loosing a 'good chunk of important functionality'). The arguements that Jesse makes and indeed my concerns are not that Flex/Zorn will standlone from the server (although this was a question that you have answered). My concerns is what the whole Flex/Zorn package holds for .NET teams. On that note I will have to wait and see what Mistral can do but my concerns remain.