Platform Choice and Implementation

-         Disconnected Applications

o       Because the .NET platform is a fully functional development environment, its applications can support disconnected architectures to a degree which is not possible in MX. Because Flash MX does not currently include XML query support via XQuery or XPath, working with large amounts of xml data can be cumbersome. Additionally, as the amount of offline data increases, performance rapidly degrades. This is due to the fact that custom query logic must be written in ActionScript.

o       Because remoting and web services are not available while in an offline mode, logic contained within server side .NET, J2EE, or ColdFusion components potentially could be duplicated by client side code. This code duplication is undesirable. With .NET, business logic can be included in the form of identical, or nearly identical, client side assemblies which execute against a local MSDE (or SQL Server CE) data store. With MX, developers may need to use ActionScript to duplicate business logic that is active during both online and offline modes.

-         Outside of the browser

o       Both .NET assemblies and SWF movies function outside of the browser without major drawbacks.

-         Standards support

o       Because .NET is an extensive platform, it supports a wide range standards, many of which are not supported by the Flash player. Because Microsoft is also a leading provider of many of the standards that are emerging in the WebService space, its influence in the standardization process reflected its product’s designs.

o       Because Macromedia originally intended Flash to be a tool for media designers, Flash does include support for many standards which are not currently supported by the .NET framework such as MP3 audio, ADPCM audio, and Sorenson Video Compression. Developers can support these standards from a .NET application by using third party assemblies or hand-coding support, but the fact remains that Flash is an optimized platform for the applications whose sole purpose is the delivery of rich media while .NET is not.

-         Prebuilt components

o       Many third party components are available for both Macromedia and Microsoft’s platforms to provide a wide variety of functionality.

o       Because.NET is a more extensive framework, components can provide much richer functionality than Flash components (for example, high performance 3D rendering libraries or operating system specific extensions).

o       Microsoft includes powerful component support through features of the .NET framework such as interfaces and attributes. Interfaces allow components to define their contracts in an implementation agnostic format, while attributes allow for many unique capabilities, such as design time support and applications that can use metadata to provide services that can easily adapt to work with components whose contracts had not been defined at during the development of the application. Because ActionScript does not support interfaces or attributes, component based development is limited by a few language barriers.

o       .NET components can interact with the IDE at design time in many ways that are not possible with Macromedia’s current component model. One example is the .NET UITypeEditor, which allows a component to fully customize the IDE’s property editor.

o       .NET controls use a very specific event pipeline which allows one control to inherit and extend the functionality or look of another control. With additions, such as the shape drawing APIs in Flash MX, it is theoretically possible to create a similar pipeline; however, this is not currently part of the built-in MX component model.

-         Multiple platforms and devices

o       Clearly, Macromedia has ported the entire Flash player to many environments on which the completed .NET framework is not available today. It is important to note, however, that the .NET framework includes a plethora of features which are not included by the Flash player, so depending on the type of application that is being designed, the set of features from the .NET specifications that is absent in a specific port of the .NET framework may be much less important than the set of features from the .NET framework that is absent from the Flash player.

o       Unlike many other approaches, which seek to provide the same experience on all devices, the Microsoft strategy recognizes that different devices have different limitations. For example, the Microsoft approach requires that applications which will run on the PocketPC have a different UI layer than those that are running from a desktop application. With all the write once, run anywhere hype, this may not seem like a good idea, but reasons behind this requirement are solid. A user interface designed for a 17” desktop monitor is not going to be readable, much less usable, when scaled down to a 5” PocketPC screen. Admitting this limitation, Microsoft’s strategy allows developers to capitalize on the strengths of individual devices, not forcing a lowest common denominator approach. Future versions of the .NET Compact Framework will include extensions for device specific features such as infared ports. Macromedia has not currently annouced plans for such platform specific enhancements.

-         Web Services

o       Simple web service consumption is painless in both Microsoft and Macromedia’s product offerings. With the added support for additional web service specifications and custom enhancements, Microsoft's offering shines as the complexity of the solution increases. Built in support for UDDI is not a big 1-up today, but Microsofts decision to include UDDI support may turn out to be a boon for .NET application developers.

-         Application updates

o       With the addition of Central, Macromedia’s platform will be the only platform of the two with fully functional application update support. It is pointless to analyze the robustness of Central's support in this area without working with the final product. Microsoft’s default application update support (via url based execution) is not robust enough to handle complex update scenarios. Although there is sample code available to aid developers in adding auto-update support, additional support at the framework level is definitely desirable.