The Flex strategy first began to crystallize two years ago when Macromedia rolled out the Flash 6 player, Flash MX development tools, and ColdFusion MX server. The possibilities were exciting, and the back-end environment was comfortably based on Java and Web services. But the client-side discipline was alien to the corporate programmer.The sample Flex app that appears in the story is the RSS reader that Macromedia's Christophe Coenraets wrote. I guess RSS readers are now the official benchmark for next-generation markup-driven development. Here's the same thing done in XAML.
One obstacle was the ActionScript 1.0 language, which lacked the strong typing and formal class model that a Java programmer would expect. The solution to this problem arrived last fall when Flash MX 2004 introduced Flash Player 7 and support for ActionScript 2.0. Yet the Flash IDE was still built around the concept of making a movie, not coding an application. Flex presents a development model that will make immediate sense to an enterprise developer. [Full story at InfoWorld.com]
It's interesting to consider these two admirably compact implementations side-by-side. Some points of comparison:
| MXML | XAML |
| Here today | 2006? 2007? |
| Runs anywhere Flash Player 7 runs | Runs only on Longhorn |
| Server required | Server not required |
| Uses ActionScript 2.0 | Uses .NET languages |
| XPath support: no | XPath support: yes |
| CSS support: yes | CSS support: no |
This mixed pattern of green (good) and red (bad) pretty much sums up my conclusion. I want all the green stuff in one column. Actually, I want all the green stuff in multiple columns: Flash, Mozilla, .NET. Heck, if I want to write a tool for Groove 3.0, I should be able to use the same XML-based UI definitions, objects, and events as I can use everywhere else. At this level of abstraction, all this stuff is too similar to justify the differences.
We had a great thing going for about 10 years: the universal HTML/JavaScript client. And while it's still a great thing, there are good reasons to advance the state of the art. But can we please, please not lose the standardization that's served us so well?
Former URL: http://weblog.infoworld.com/udell/2004/03/31.html#a960