The War of the Web, Part 2: Microsoft vs Macromedia 6

It is now more or less obvious that the browser wars are dead for good.
But that does not mean that the battle of the web is over. This time
the main battles are all about Rich Internet Applications.

A few weeks back Microsoft introduced Avalon and
XAML. Now it is time for
Macromedia to unveil their product, currently called Flex. Flex is
an XML UI language, much like XUL,
but contrary to XUL it requires both
a server side component and the Macromedia Flash player (which I don’t have
installed). However there is no need to update the client viewer. The server
compiles the MXML (the name of the Macromedia Flex XML format) to a normal
Flash movie that can then be used by the Flash player. This gives Flex a very
large user base since the coverage of Flash is supposed to be even larger than
the covarage of Internet Explorer. 98% for Flash according to Macromedia and
something like 90% for IE as far as I recall.

Flex, unlike XAML, is heavily based on existing technologies so one does not
have to relearn everything (MSFT decided to scrap every known standard solution
that is working today). Of course, they (Macromedia) are not short to point this
out. Some of the more interesting technologies they have listed are:

  • DOM Level 3 Events.
    Basically this means that they will also need to support at least
    DOM Level 2 Core.
  • ECMAScript 4 (also known as Javascript 2.0,
    7 or Jscript.NET
  • Cascading Style Sheets. There wasn’t much info about what parts of CSS they
    plan to support. Macromedia has always been a bit behind when it comes to CSS
    and the code snippets in the white papers contained a few CSS errors.
  • SVG
    for shapes and other vector drawings. This is very interesting since SVG is basically a Flash
    killer technology. I wonder if they (or someone else) could output SVG 1.2 documents instead of
    Flash movies at the server side?

I’ve never been much of a Macromedia fan but I must say that Flex looks
pretty promising. It is indeed going to be some very interesting years ahead.

ps. I wanted to do a few comparison comments to XUL but this post is long as it is. Maybe tomorrow.

  • Emil


  • Erik Arvidsson

    Why “Why?”?

  • Lucas Fletcher

    The question I have never heard ask is what are the intrinsic limitations of DHTML that prevent it from being used for Rich Internet Applications? Why must advancements in architecture be a constant ongoing process of the child devouring its mother? I know coders love to start with a blank slate and corporations love to own standards, but still. It’s a cop-out quite frankly. It’s giving up. And it really pisses me off. Yes, integration of new technology into existing is a tough row to hoe, and it takes _creativity_ more than anything else. But it can be done, and the end result is not having to make trade-offs based on the platform you use.

  • Erik Arvidsson

    I believe that a lot can be done using DHTML (just see Bindows) but I think it is more suitable to create standardized widgets on a much lower level. Creating widgets at a DHTML level is possible but it is just like in the old DOS days when people created their own GUI toolkits. I think there needs to be a standard GUI toolkit with both speed, scalability and usability taken into account. If you look at the existing GUI toolkits built on top of DHTML or Macromedia Flash they usually lack in at least one of these fields. Heck, I have yet to see a usable Flash application. Somehow all the Macromedia people forgot that keyboard navigation should work as well (See Laszlo as a good example).

    Another serious downside to DHTML (except for scalability) is the fact that it is based on CSS2 for its rendering model. A modern GUI should be vector based. However this does not stop DHTML from being good enough today but I don’t think DHTML will be good enough in a few years.

  • Lucas Fletcher

    Let me try to address some of the points you make, all of which are good:

    1. Speed – In my experience modern machines do not have problems rendering even very complicated DHTML-driven pages in sub-second times if they are written to pull dynamically — e.g. a tree control that fetches nodes from the server when the folder is opened. Certainly by the time systems meet the Longhorn requirements speed will just not be an issue at all.

    2. Scalability – Yes browser based caching is pretty crude (caching being the only thing I can think of that would affect server scalability.) but it couldn’t be very hard to imagine how one could build extensions to allow dynamic cache manipulation and access. (Think a more robust userData behavior.)

    3. Usability – Yes, because DHTML allows so much freedom that freedom is abused often (like PERL) but toolkits address this.

    4. Not vector based – The only advantage I can think of for this is to adapt to a wide range of dpi. To be backwards compatible Longhorn is having to scale pixel-based apps to fit the new monitors they envision, so in a sense pixel-based apps can be made scalable. (and though it may not be as clean looking as vectors it still looks quite good)

    Web standards are not going anywhere, they will be around for a very long time. It is probably the most locked-in platform that computing has ever seen. Given that, MS must really think the alternative browser crowd has their thumbs up their asses to stop innovation on IE.

  • Ahmet Zorlu

    imho, XAML is specific to the upcoming Longhorn OS and is something more generic: a declarative programming model for working with Common Language Runtime object graphs. It can be programmed with any .NET language and the environment comes free with the OS.

    MXML on the other hand, is a web-oriented system for serving swf files using a servlet model. MXML is more specific and (as far as I understand) target audience of FLEX is enterprise, and not the mainstream web developers (which is a big obstacle for its adoption, especially if MM will fail to release a developer version).

    One note about ActionScript 2.0; although the lexical structure of the language fits (to a great extent) EcmaScript v4. specs, when it is compiled to swf, it is compiled to almost exactly same bytecodes as AS 1.0. The runtime (currently) supports EcmaScript v.3 model. So namespaces are objects, classes are actually functions, and the inheritance is prototype-based. There is no method overloading, no run-time type checking. Programmers coming to AS 2.0 from class-based languages should be aware of this fact.

    Good blog, by the way.