Summary
We've been working on an XML syntax for generating compositions of rich UI components from web apps, rendering them in the ubiquitous Flash VM, and binding them to remote data and services. Previously code-named Royale, it enters beta with the official product name "Macromedia Flex."

I have a confession to make: I completely believe in the benefits of Rich Internet Applications, whether Flash-based or not, but I want to develop them differently than my own company has previously allowed. I personally dislike developing in the Flash authoring tool. Now, I think my friends on that team have done a brilliant job at building for the designer/scripter community, but that community doesn't really include me. I personally don't use the Flash timeline, I'm not much of a visual designer, and I don't quite get some of the APIs and terminology (like using the "stage" to develop "movies").

Enter Flex.

Developed in your favorite IDE (or in our DreamWeaver-based visual editing tool, as you might expect) and deployed into a Java web tier (a .NET version is also likely), the resulting rich clients are rendered in our ubiquitous Flash VM. The client-side components might take advantage of client-side storage, client-side validation and the like. But they also might bind simply and directly to remote web services, remote Java constructs (JavaBeans such as Struts models, for example, or even EJBs), or to REST-based resources such as XML files delivered over HTTP. The syntax currently referred to as MXML simplifies all of this. By the way, I have a feeling the product managers aren't done renaming things yet so if the syntax is named differently in a final release, remembering I told you it was originally 'MXML' may eventually win you some geek trivia contests.

The Syntax

Want to use this syntax to generate a rich, smart datagrid amid your otherwise JSP-based web app? Can do, our syntax is happy inside or alongside JSP.

Want to use some SVG inside MXML? Sure, go right ahead.

Want to style some of the components using CSS? Sure thing, go to it.

Want to add logic that can't be accommodated in standard XML, some client-side glue code that you don't really need in a full-blown remote Java service? How about using simple script -- JavaScript, actually, but with support for ECMAScript classes should you need it (for better or worse we call this ActionScript).

Want to bind to an existing Struts JavaBean-based data model? Go ahead.

Want to bind to a set of SOAP-based web service inputs and outputs? Very easy, services are first-class citizens at the highest level of the syntax.

Want to create the UI components themselves in Flex? Ok, you can use simple script to do so.

Want to keep using Flash MX authoring, or continue working with creative designers who use Flash authoring? Sure, you can use the components that these folks whip up.

Want to use Eclipse, or IntelliJ, or emacs to craft your rich apps? Go right ahead. Since the syntax is schema-based, you'll also get smart editing in some of your favorite non-Macromedia development tools.

Courting the Comparisons

Comparisons might reasonably be made to XAML and to XUL. XAML links CLR-based types in a way similar to our linkage of script-based classes and rich components, and XUL is a great way to arrange components, style them using CSS, and handle events using script within a Mozilla container.

XAML and MXML diverge from XUL in supporting a fairly different services model and data model (XUL goes with RDF in extensive and sophisticated ways, whereas we try to stick with XML Schema), rendering to a vector graphics layer to abstract hardware and other dependencies, and not requiring the deployment of a container like Mozilla (although I guess XAML might require an even larger container -- Longhorn). We also allow the creation of new components by developers using script and by designers using our Flash authoring tool, and I think that XUL component creation requires use of XPCOM. Some of the UI syntax is very similar, but it would be wrong of us to pretend this is literally XUL when that's the only deep similarity.

XUL and MXML diverge from XAML in that we can be cross-platform, deploy even to pre-Longhorn Windows systems, and are very web-centric; XAML targeting Avalon appears to be aimed primarily at desktop applications -- this suggested by Chris Anderson, a Microsoft architect whose blog I enjoy. If it's primarily for desktop apps, I interpret it as an intended replacement for .NET Windows Forms. I didn't hear much about XAML and Avalon for web applications, and talk of the browser was mostly absent from Microsoft's PDC. But despite the real need for a smarter client (Central, anyone?) I don't think cross-platform browser-based web apps are likely to die any time soon, so it's a good thing that you can get the richness within a browser.

In future entries I hope to dig down deeper into the Flex syntax and runtime services, and take a look at how it compares to similar options. It seems to me that we could have bent over backwards to extend XAML or XUL to a similar end, but I'm not sure doing so would produce exactly what developers want: a simple way to produce cross-platform, rich and smart, service-oriented clients that can be managed within existing server-side infrastructure and target an existing ubiquitous client.

It will be interesting, though, to hear if I'm wrong and we should make more use of XAML or XUL. I'm an engineer, and don't speak for my company here on these pages, and don't have a stake in any religious battles. I am interested in hearing genuine technical feedback, though, that suggest changes we ought to make or stupid things we ought to fix. Macromedia is not a small company, and not everyone "gets it" in the same way, so whether obscenely offended or quietly constructive, please make sure we're getting it with Flex.

Code Samples and the Flex Beta

My friend and Flex evangelist Christophe Coenraets has started blogging about Flex, and has a great intro whitepaper with some sample code: http://www.macromedia.com/devnet/flex/articles/paradigm.html. You can also follow that link to apply for the Flex beta program.

Talk Back!

Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Sean Neville adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Sean Neville is a software architect at Macromedia where he is focused on creating the Flex platform. His previous projects include the JRun application server and Flash-related products for J2EE and .NET. His experiences include membership in the JCP Executive Committee and numerous JSR expert groups; authoring articles, contributing to books, and speaking on enterprise topics; financial services app consulting; building doomed yet fun web startups; maintaining open source projects; and half-decent fiddling of Irish jigs and reels.