The buzz over AJAX aside, Microsoft’s first effort in the AJAX space was disappointing. ASP.NET 2.0 will ship with a technology called Script Callbacks (http://www.asptoday.com/Content.aspx?id=2381) that is native ASP.NET. Script Callbacks are simple and quirky, an interface-based implementation of page callbacks that are entirely bound to the ASP.NET page lifecycle. Although 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 easier and more fully implemented solutions available from the community. I personally like Jason Diamond’s My Ajax.Net (http://jason.diamond.name/weblog/2005/07/06/my-ajax-dot-net-library) and have used it quite a bit. Another popular library is Michael Schwarz’s Ajax.NET (http://ajax.schwarz-interactive.de/csharpsample/default.aspx), 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. They also 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 including 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 to ship 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, 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, but it’s important to understand that not all of the features in 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 that 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 provides 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 need 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 they 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 because 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 preliminary tests, I found this mechanism, in combination with the rich type support, very powerful. The ability to pass complex types and collections of types from the server to the client and back easily 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 with business data, this mechanism really provides clean separation of the UI and business layers.
As mentioned above, Atlas provides a rich client framework that supports 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 have not been provided, but it was shown by Nikhil Korhan (http://www.nikhilk.net/) in the Server Control talk (http://www.nikhilk.net/Entry.aspx?id=92) 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 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 me 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 that 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 that the same will happen here.
The Good, the Bad and the Ugly
Looking at Atlas in this early stage is a mixed bag. As with many previews, the documentation is nearly non-existent beyond a few hands-on labs that give a cross section of the features available. The labs are actually quite good at demonstrating a number of common scenarios, from the most basic to the cool factor. But the labs are not a good substitute for documentation. They only address a very minimal subset of the capabilities and provide absolutely no insight into how things work behind the scenes, which at this point, would be beneficial.
I spent some time going 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. Even some of the simple steps failed outright. Working from the labs and trying to use the server control markup to fire custom code also proved difficult-I was stopped dead in my tracks at nearly every corner due to lack of documentation.
Playing with Atlas at the moment is beyond even bleeding-edge technology. Don’t spend 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 now other than checking it out and giving Microsoft feedback about 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 deterrent to efficient client-side and AJAX development is the lack of tools to debug your client-side script code. Writing client script code is easily four to five times slower (for me at least) than it is to write the equivalent server-side code. Lack of IntelliSense, compilation, and the 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 via the client-side markup. By using these client-side libraries, Microsoft is able to abstract away some of the browser compatibility issues and provide the developer with a 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 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 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 like Web applications, by 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 on 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 on which to build Web applications 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 love to be proven wrong by time. <g>
I think Microsoft comprehends 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, it will provide an easier way for ASP.NET developers to get there.
Time will tell, but it’s an interesting start.