David Mendels, who is with the Flex team posted some comments on Flex. I thought they were really good, so here they are:
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.