This evening I presented at the Victorian Dot Net User's Group on ATLAS.  For those of you who attended who are interested in the code, it's attached to this entry.  Also, I should thank Mr Glover for providing the basic materials/slides/resources for the session :)

All in all, I think ATLAS is a pretty good step in the right direction if you are looking to build a rich user experience in DHTML.  One of the things I really like about ATLAS is how well it protects you from having to think too hard about the browser the code will run in.  In the ATLAS model, you code against the ATLAS core, and ATLAS takes care of translating this into the DOM of whatever browser the client-side app happens to find itself in.  I remember from a previous life how hard it was to get DHTML code working convincingly well with cross-browser targets.  In short, the development experience was horrendous: Netscape's DOM was different from IE's DOM, and IE 5.5 on the Mac was different from IE5.5 on Windows.  Some products like GoLive from Adobe seemed to help a little, but they still tended to break down when things started to get, well, complex.  ATLAS on the other hand seems to handle this very well indeed - the ATLAS guys have done an excellent job of this.

I also like the declarative model for binding control data, and the UpdatePanel/PartialRendering functionality is just magic.  It'll be cool once there's more designer support for ATLAS in VS2005, so I can use intellisense instead of clogging what's left of my short-term memory trying to remember the properties and methods of various ATLAS objects.

Bill McCarthy (who had presented earlier in the evening on DSLs) asked me during the session whether ATLAS required any ActiveX controls on the client side in order to work.  I confidently replied 'of course not, ATLAS is basically a bunch of very clever client-side scripts that are downloaded as part of the normal browser page-request process...'.  Of course, I forget that in fact there IS at least one ActiveX control that is being consumed by the ATLAS framework, at least in IE.  That control is - duh - MSXML.  How else is the ATLAS runtime going to parse all that XML declarative stuff on the page? :)  Ok, so my somewhat shaky defence to this faux par was that I was thinking about the nasty kind of activeX control that hijacks your machine and sends your browser off to the nether regions of the internet to purchase stuff from online drug-stores, not the benign kind of ActiveX controls that are COM libraries for doing useful stuff on behalf of a script.  For the record, that other browser - it's name eludes me right now - has an XML parser built in.  You can see what I mean in the following code from atlas.js:

window.XMLDOM = function(markup) {
    if (Web.Application.get_type()== Web.ApplicationType.InternetExplorer) {
        var progIDs = [
'Msxml2.DOMDocument.6.0', 'Msxml2.DOMDocument.5.0', 'Msxml2.DOMDocument.4.0', 'Msxml2.DOMDocument.3.0', 'Msxml2.DOMDocument' ];
       
        for (var i = 0; i < progIDs.length; i++) {
            try {
                var xmlDOM = new ActiveXObject(progIDs[i]);
                xmlDOM.async = false;
                xmlDOM.loadXML(markup);
               
                return xmlDOM;
            }
            catch (ex) {
            }
        }
       
        return null;
    }
    else {

        var domParser = new DOMParser();  // AHEM....
        return domParser.parseFromString(markup, 'text/xml');
    }
}

There was some philosophical discussion afterwards about the nautre of browser applications.  I must admit to feeling somewhat... ambivalent... about AJAX as as model for developing applications.  Sure, AJAX helps address user experience shortcomings with HTML/HTTP round-trip latency, and libraries like ATLAS address the coding experience side of the equation, especially in the face of diverging DOMs and a rather average scripting language in the browser. 

However, the key point here is that there is a tension between what we WANT to do in the browser, and what the browser can actually do for us.  ATLAS, and libraries of it's ilk are a response to this tension.  If you extrapolate this thought, the tension becomes selective pressure for the browsers to get better, from both a UI as well as development perspective.  I think that this actually means we are staring down the barrel of a good old fashioned arms race in the browser world (which shouldn't be news to anyone).  There are things we'd like to do in the browser that we can't because the technology isn't up to it.  AJAX style libraries go some way towards addressing this, but what is really required is innovation in the browser, or innovation in other technologies that provide a better experience for web users and developers.  Think XAML, flash, embedded .NET controls, embedded Java controls, and other technologies that haven't been dreamed up yet.

The outcome of this arms race is unclear, but was is clear to me is that the browser's we'll all be using in five years time will be quite different current beasts we know and love (or hate) today.  It'll be interesting to see how this turns out.

In the meantime, is AJAX dolling up the swine?  Perhaps.  Is it useful technology and here to stay for the next while?  Absolutely.

[UPDATE] - Tim Heuer has posted some great samples that work with the Jan ATLAS CTP at http://www.asyncpostback.com/