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
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.
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.
Client Side and Server Side Controls and ‘Atlas Script Markup’
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 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.
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.