At the Professional Developer Conference (PDC) in September Microsoft offered a first glimpse at its AJAX (Asynchronous JavaScript and XML) strategy which has been given the codename of Atlas. As you probably are aware of, AJAX is the current over-hyped buzzword in Web Development. It promises the ability to write richer browser applications and retrieve data from the server to update the content of the current page without having to completely repost the page to the Web Server. The advantage of this type of application is that it provides more efficient usage of the bandwidth available to Web applications and – in many cases – provides a smoother, more responsive and non-flashing user interface that Web applications are typically not known for. On the flipside AJAX relies on more recent browsers and fairly extensive use of client side script code to provide the rich interaction between the browser and server.


The hype over AJAX aside, Microsoft’s first effort in the AJAX space was a disappointing one. ASP.NET 2.0 will ship with a technology called Script Callbacks that is native ASP.NET. Script Callbacks is a simple and quirky, interface based implementation of page callbacks that are entirely bound to the ASP.NET page lifecycle. While functional, the model used in this architecture is both limited and implemented in a way that makes using it rather cumbersome and unnatural. Microsoft developed this technology for internal use early in the ASP.NET 2.0 cycle before AJAX became fashionable. It’s used internally in several of the ASP.NET server controls like the GridView and TreeView to support client side updates of the data displayed.  


If you are looking to do AJAX style development with ASP.NET 1.1 or 2.0 today there are other possibly easier and more fully implemented solutions available from the community. I personally like Jason Diamond’s My Ajax.Net and have used it quite a bit internally. Another popular library is Michael Schwarz’s Ajax.NET which is probably the most used AJAX implementation on .NET today. Both are open source and come with source code and more importantly both are easy to use and provide simplicity for the 90% use case scenarios and they work with ASP.NET 1.1 so you can use it in all of your ASP.NET applications.

Atlas to the rescue

Not to be outdone, Microsoft entered the AJAX space for real with the announcement of the Atlas Project just a few weeks before PDC and officially previewed the technology at the conference. As expected Atlas is a very ambitious project and covers a huge range of features that cover a variety of approaches to implementing AJAX style applications. Atlas is slated to be shipped as an add-on to ASP.NET 2.0 sometime in 2006, so it’s still a ways off. One nice thing announced is that Microsoft is planning on shipping Atlas outside of the regular ASP.NET product cycle initially so the product can rev much more quickly than a full ASP.NET cycle. Atlas likely will ship as an add-on assembly (or assemblies) plus a script library that can simply be added to an application. At a later point in time it’s likely that tool integration with Visual Studio will take place resulting in a tighter binding to the core ASP.NET platform.


So what does Atlas bring to the party? A lot of things actually, but it’s important to understand that not all of the features of this overwhelming library are necessary to start doing AJAX style development. Here are the some of the core features:


Web Service Connector Bridge

One of the core features of the Atlas framework is the ability to bring down data to the browser quite easily by using a new Web Service interface that gets hooked by the Atlas framework. This special HTTP handler interface essentially allows an Atlas client application to communicate with a .NET Web Service using the JSON serialization format. JSON is a JavaScript compatible, light weight serialization format that encodes any type including complex type into a string that can be evaluated in JavaScript and provide a type reference. This simple interface allows you to take advantage of existing Web Services – or new ones – to access server side logic from the client applications without all of the overhead that SOAP entails.


This interface is two-way, so you can receive data from a Web Service and you can send it back up to the server using the same mechanism. Atlas can serialize and deserialize the JSON format both on the client and server. To facilitate this process the Atlas client framework includes the infrastructure to manage type information which becomes part of the JSON serialization strings that travel over the wire. What’s really nice here is that in combination with the client side script framework you can return many common types from the server and use them easily on the client. For example, you can return arrays, collections, data tables and data rows and the client framework will provide a CLR like client implementation of that type. Custom types are also supported.


This deceptively simple implementation provides a lot of power to existing applications that might not even want to take advantage of all that the Atlas framework has to offer. This is a close match in functionality to the tools I mentioned earlier only more closely integrated with standard ASP.NET practices.


Web Service methods can be implemented both in a separate Web Service class or can be called directly in the current page. One interesting feature of the page based WebMethod call is that all of the page’s POST data gets written back to the server and the callback with full support for the page lifecycle including access to updated control values and ViewState. The full Web Service interface can work with current ASMX implementations or with Indigo services.


Personally I prefer the external Web Service approach as it promotes better separation of the UI logic and the data service functionality. Using the Web Service also means that the data is much more reusable. For example, if you end up building a true Smart Client application it will be able to consume the exact same data using a standard Web Service from exactly the same code base.


In some preliminary tests I found this mechanism in combination with the rich type support very powerful. The ability to easily pass complex types and collections of types from the server to the client and back makes it quite easy to update the user interface, modify data and send it back  without having to resort to writing complex string encoding schemes to pass the data around. For interfacing wit business data this mechanism really provides clean separation of the UI and business layers.


Client Side JavaScript Framework

As mentioned above, Atlas provides a rich client framework that provides many of the core services required by other parts of Atlas. Atlas uses a layered client architecture of services provided by the framework. Most of these layers are internally used such as the rendering features for controls, the browser compatibility layer and the network layer used to send requests back and forth.

But one layer you’re likely to see a lot of in your client applications is the Core framework and Base Class Library which provides a small subset of .NET CLR and BCL functionality on the client side. The Core functionality provides a number of language features that are interesting. There’s namespace support and type registration to provide a simulacrum of typed JavaScript variables. Perhaps most interesting is the client-side BCL implementation which provides support for many common basic classes and structures that are used in .NET development. This means that the code you write on the client script end, looks a lot closer to .NET code than it currently does even if some constructs are bound to quirky JavaScript language features.


Client Side and Server Side Controls and ‘Atlas Script Markup’

In addition to the framework Atlas also provides a core set of controls that provide browser independent implementations of many common ASP.NET controls. What this powerful feature buys is an abstracted control model that alleviates the developer’s need to fully understand the nuances of every browser running on a client. If you’ve ever done any sort of UI development with client side JavaScript you know that the syntax and object models of various controls varies ever so slightly and these client side implemented custom controls alleviate the need to have to code to these browser specific nuances.


It’s hard to tell right now how this works, but the Atlas framework uses these controls internally to manage the browser independent rendering of script code. Examples of this stuff have really not been provided but it was shown by Nikhil Korhan in the Server Control talk at PDC. At the moment these controls are internally used by the Atlas Server Controls and the ‘script markup’ they generate in the client side HTML page. Atlas basically uses declarative script tags to drive functionality through behavior attributes. For example, you tell the control to invoke a method on another control (or data control) to retrieve the data, or set the value of a given property.


The script markup is interesting in that server controls generate their declarative markup to the client as is within an embedded <script type="text/xml-script"> tag. The Atlas client framework then evaluates this script markup dynamically to generate the actual page behavior and layout. In other words, unlike server controls, these controls use the client side controls and framework to manage the parsing and even code generation at runtime in the browser. This takes a moment to grasp. The reasoning behind this client side parsing and execution seems to be to avoid having to generate reams and reams of JavaScript code and injecting it into the page before sending it from the server. By doing it on the client this markup functionality can be easily added to any page and can stay relatively small describing the actions of the page.


Microsoft seems to be emphasizing this declarative style of programming, but that doesn’t mean that script code driven logic is not available. You are absolutely able to drill down to the script level and write the control code and logic yourself. If you do you can take advantage of the control architecture and BCL implementation so you get much richer client side functionality. But keep in mind that some of these features are hacked together around the limitations of JavaScript, like the Type subsystem and Object Oriented featured in general. It’s still JavaScript. Bend it as they might, Microsoft is sticking to a pure JavaScript implementation.


This is all pretty vague at this point as there’s zero documentation, but it shows the direction that Microsoft is headed. The idea for the markup code is that rather than writing potentially browser specific JavaScript code you write declarative markup that the Atlas framework then renders into control code and script code that is dynamically generated and executed at runtime. Bertrand LeRoy has a nice example that demonstrates the server control/markup syntax a lot better than the simplistic PDC labs. In that example, you can get a pretty good idea of what markup will be capable of by providing a very UI centric interface.


While I think that this is a noble goal, I personally have many misgivings about this declarative model, because it’s completely UI centric. You basically map a Web Service (or other datasource) to a property or method of another control, but there’s very little room for custom code that is almost certainly going to be required in addition to 1 – 1 mappings. In addition the markup model introduces yet another ‘scripting’ layer into your applications with yet another different markup syntax. However, all of the markup actually gets translated into JavaScript that eventually executes.


The functionality of this markup reminds of Ruby on Rails to some degree, and it’s a model that I dislike vehemently. I don’t trust code that is handled for me to serve all of my needs and this has the beginnings of a high level description language that doesn’t sit well with me. I have to admit I had similar misgivings about the template driven approach that ASP.NET controls use, and eventually I came around to it once I understood fully what you can and can’t do with that approach. I expect the the same will apply here.

The Good, the Bad and the Ugly

Looking at Atlas in this early stage is a mixed bag. As with many of these types of previews the documentation is nearly non-existent, beyond a few hands-on labs which give a cross section of the features available. The labs are actually quite good at demonstrating a number of common scenarios, from basic to the cool factor type. But, the labs are not a good substitute for documentation. They only address a very minimalist subset of the capabilities and provide absolutely no insight into how things work behind the scenes which is this point would be beneficial.


If you want to know how things work your only avenue is to open up the JavaScript libraries with their bunched up, line-feed removed code and dig through the spaghetti code that is JavaScript even at its best. Most of the meat of Atlas is in the JavaScript. For the server side code you’ll need to dig out your copy of Reflector and start digging into the binary bits. Looking through all of this you’ll find that there’s a lot of implementation code – Atlas has been a while coming at Microsoft.


I spent some time to go through the labs and that worked just fine, but as soon as I started going off the beaten path a number of things started breaking. For example, the Web Service functionality started breaking on even some simple custom types I set up. There’s no exception handling in the Web Service behavior so if anything goes wrong on the server, or you need to notify the client of a non-success result via a SOAPException, the server spits back HTML instead of an Exception or other object that includes an Exception. So even some of the simple steps failed outright. Working on from the labs and trying to use the server control markup to fire custom code also proved difficult – basically I was stopped dead in my tracks almost at every corner due to lack of documentation.


Playing with Atlas at the moment is beyond even bleeding edge technology. Don’t waste your time with it unless you’re willing to dig into the code base and find your own ‘documentation’ there.


But this is understandable from Microsoft’s point of view. It’s meant as a very early glimpse at what Microsoft is doing. I don’t think there’s any hope of doing anything useful with this technology at this time other than check it out and give Microsoft feedback on direction. One thing is for sure: this stuff is likely to change drastically, so don’t get too familiar with what’s there today.

Pain Factor: Client Side Scripting

Atlas provides a lot of technology and functionality at the library level, but it doesn’t provide any new tool support at least not at the moment. I would argue that the biggest detriment to efficient client side and AJAX development is the lack of decent tools to debug your client side script code. Writing client script code is easily 4 to 5 times slower (for me at least) than it is to write the equivalent server side code. Lack of Intellisense, compilation, and the mere lack of decent documentation for the various object models make all of this difficult.


Microsoft is addressing some of these issues with the client side libraries and bringing a more consistent object model to client side code so via the client side markup. By using these client side libraries Microsoft is able to abstract away some of the browser compatibility issues and providing you as the developer with a more consistent single access model to code against. This is an important step in the right direction, but tool support is absolutely required if we are to build applications that will rely on an increasing amount of client side logic.


Client side debugging is not being addressed at the moment. That support is something likely to come in future versions of Visual Studio

Smart Client and Thin Client – No Contest, Yet!

There are some interesting issues that Atlas brings up. It’s obvious to see that Microsoft has heavily invested in Atlas by the sheer breadth that this toolkit attempts to address. With all the talk about Windows Vista and Avalon – uh, Windows Presentation Framework (WPF) and the return of the Smart Client, it’s also clear that Microsoft sees the importance of Web based applications and continues to provide tools to build rich applications for this platform.


Try as we might, rich client advances to date have had very little impact on how Web applications or distributed applications are run at least for outward facing applications. Even though it is now nearly as easy to create rich client applications that run inside of the browser, the Web paradigm is still way, way more prominent than any rich client distributed scenarios. Smart Client applications continue to be a hard sell when it comes to public content. With the coming of WPF and the XAML markup language, Microsoft surely is hoping to have a compelling platform to build rich client applications that can directly run in the browser just like Web applications, but taking advantage of the super rich presentation layer that WPF provides.


There’s no doubt that WPF has huge potential to provide this rich and powerful platform, but it’s by no means a foregone conclusion that it will take off for Web style distributed applications. Imagine that you could build rich applications that take advantage of all that Windows has to offer from rich rendering to advanced layout and databinding running native .NET code that you can actually debug. Wouldn’t that be nice? But I wouldn’t count it becoming a mainstream reality anytime soon, as much as I would love to see it happen.


This smells very much of the Internet Explorer 4.0 model where IE at the time was a much more compelling platform to build Web applications for than most other browsers of the day. But even so it never took off as a dedicated platform with Web developers and developers in general sticking to a more generic approach that worked across platforms. We shall see – I would actually love to be proven wrong by time <g>…


I think Microsoft realizes the continued importance of pure Web development and Atlas is a sign that this path will continue, even if it potentially has a negative impact on the adoption of WPF based Web interfaces. Atlas squarely steps in the path of WPF providing a model for building rich Web applications that can provide a more interactive user experience. Advances in the Web client platform have been in stagnation for quite some time, and hype or not, AJAX is injecting a new vibrancy and energy into the Web application platform. Even in its simplest form AJAX style Web applications can provide a better user experience and more interactive applications at the cost of a more complex client/server model. Atlas promises to ride that wave into new territory and possibilities for Web applications and hopefully provide an easier way for ASP.NET developers to get there.


Time will tell, but it’s an interesting start.