A few weeks ago Microsoft announced new naming for the product formerly known as Prince – eh, ATLAS.  The names Microsoft came up with are the ultra-catchy Microsoft AJAX Library for the client side JavaScript framework and Microsoft ASP.NET 2.0 AJAX Extensions. Rolls right off the tongue, doesn’t it? All kidding about the boring names aside the new names are  descriptive of the functionality and they include AJAX in the name so it’s quite clear what their purpose is. I suspect it will take a while to lose the ATLAS moniker though and I’ll use it here to keep it short.

The Roadmap

Once codenames like ATLAS come off, it’s usually a sign that the technology is heading down the road to the marketing department which in turn means that it’s getting at least somewhat close to a release cycle and feature lockdown. Scott Guthrie announced the roadmap (http://weblogs.asp.net/scottgu/) for ATLAS which calls for a 1.0 release sometime at the end of the year with a public beta and release candidate between now and that time.

This initial release is set to be a ‘core’ product that provides the base AJAX client and server functionality. According to Microsoft this will include most but not all of the features that are currently supported by the ATLAS CTPs. The rest of the controls are still going to be provided but they may not be part of the core supported set for the 1.0 release and will continue to be improved upon with further CTPs.

It’s a bit confusing, but the goal is to push out a full release of ATLAS soon so that developers can include “official and supported” Microsoft AJAX technology in their applications without running pre-release software. I know this has been a concern for me personally as I’ve not been able to integrate ATLAS into my own tools due to issues with unsupported software for our customers. So to date I continue to use and update my own AJAX library while spending my time getting up to speed with ATLAS.

The 1.0 release is a framework release only and doesn’t include any tool support, so don’t expect better JavaScript or special designer support for creating client side code or controls.  Tool support is scheduled for the next release of Visual Studio code named Orcas which is rumored to go into early previews around the time ATLAS 1.0 ships. Orcas focuses on the next generation of tools from Microsoft including Vista and .NET Framework 3.0 support tools as well as tools for the ASP.NET AJAX tools. The final release of this next version of Visual Studio however is a long ways off – Microsoft has hinted at projected release at the end of next year, but I wouldn’t hold my breath given the scheduling delays Microsoft developer tools have been going through for the last few major release cycles. In short, for the moment don’t consider getting improved tool support for your Microsoft AJAX applications any time soon.

Where are we at?

Atlas has come a long way since the first presentations that Shanku Niyogi and Nikhil Kothari gave at PDC about a year ago now. I remember sitting in both those session being both excited and massively overwhelmed. I also remember looking around the room at a bunch of shell-shocked faces who appeared to feel similar. There was excitement, but also a lot of trepidation of the complexity and sheer size and functionality of what this AJAX framework promised. Microsoft doesn’t do anything small, and the ATLAS framework is a monument to that very approach. It provides a variety of different mechanisms by which to create rich browser applications. You get a server centric approach that abstracts you from JavaScript and client side code altogether, or you can use the Web Service Bridge to provide a more pedal to the metal approach using raw JavaScript. And if you’re really adventurous (at this point) you can use the client side JavaScript library, which is very powerful but complex and woefully undocumented at the moment (the source is the documentation).

In a way ATLAS and the inner workings of ATLAS have a level of complexity that rivals the ASP.NET engine itself. Luckily, just like ASP.NET it’s not necessary to understand all the details of how it works to use the technology effectively, but if you are one of the geeky types like me who likes to understand how the technology works and how each of the mechanisms impacts your application’s performance and design, you’ll have some spelunking to do beyond the 5 minute walkthroughs from the ATLAS Web site. The same is true if you plan to build controls that are ATLAS enabled. Currently there’s no clear path to building ATLAS enabled controls that have both client and server components. Make no bones about it ATLAS is a complex framework and there a lot of issues that you need to consider to build effective applications even if some of the features like UpdatePanel appear to be super simple and almost too good to be true.

A lot has changed from that original framework since the original showing at PDC. To some extent ATLAS was changed by community input. Immediately following PDC Microsoft released a very rough preview as a work in progress and looked to the community input on various forums to see how people applied the technology, what worked and what didn’t. Some features were pulled, others downplayed a bit (XmlScript for example) and some improved considerably (UpdatePanel) due to popular demand. Microsoft has been very responsive to community input, and some of the changes that have occurred to the framework appear to be customer driven which is very encouraging.

As I’m writing this we’re at the Community Technical Preview (CTP) stage, which means ATLAS is still a pre-release, pre-beta product. However, the last few releases have been fairly stable both in terms of code stability as well as feature creep. It’s been nearly two months since the last CTP (July) so it looks like a lot of work is being done at Microsoft to ramp up for a milestone release. According to Microsoft sources a beta release is not far off.

Even so I think an end of year release is pretty optimistic, given that there are a still a number of open issues, especially in the server controls that haven’t been adequately addressed and with 3 months to the end of the year it seems that time’s getting short. I’d prefer a solid first release over meeting an artificial end of year deadline.

Taking Atlas on the Road

Over the last couple of months I’ve given a number of ATLAS presentations at user groups and Code Camps and I’ve had a chance to talk to a fair number of developers and hear and see their expectations and reactions to the ATLAS technology. ATLAS has come a long way since PDC and it’s become a lot easier to use, so it’s much easier to present ATLAS as technology that can be used today in your applications.

I still am convinced that most Web applications can do just fine without AJAX technology and if they do use it, they can and should use it judiciously to provide additional functionality to the application. But in the right situations AJAX can provide definite practical advantages and that’s what I’ve been focusing on. I always ask the question of how people intend to use AJAX functionality in their applications and not surprisingly very few have a good idea how they want to apply the technology. AJAX doesn’t fit everywhere and I think it’s certainly not a new paradigm as some people paint the technology.

It’s interesting to see how the expectations of what AJAX is and how it should work seems to polarize into two clear camps: Those that want a very lightweight mechanism to call server functionality, and those that just want an easy mechanism to do AJAX.

ATLAS actually addresses both of these scenarios rather well, but I’ve been surprised that there’s a lot of resistance to ATLAS – sometimes bitterly as if ATLAS were raining on somebody’s parade. This resistance tends to come from early adopters who are already using other AJAX libraries, which are in many ways easier to use and much more light weight than ATLAS. There are many other choices out there like Anthem.NET (anthem-dot-net.sourceforge.net) which I happen to like a lot, Ajax.NET (www.ajaxpro.info) as well as non ASP.NET specific solutions like Prototype (prototype.conio.net) or Dojo (/dojotoolkit.org). I’ve been also been using a home grown library (www.west-wind.com/tools/wwHoverPanel) for some redistributable tools. Third party vendors have also started to crank out proprietary AJAX implementations some of which are very powerful and easy to use. These tools work well and for the most part are very lightweight and easy to use. Compared to them ATLAS at first blush feels like an elephant in a porcelain store.

So, for existing AJAX developers, why bother with ATLAS? My first suggestion is if you have something that works well for you, and you are comfortable with the tool, you should consider sticking with your existing solution. There might be technical reasons to move to ATLAS, but more likely the reasons are going to be political. There are good reasons to use a tool that comes ‘in the box’ or at least from Microsoft. If you’re a vendor or tool provider you certainly want to minimize your external tool footprint. I know I find myself in this spot quite a bit as I have some tools that I sell where I want to avoid third party tools, so my choices are either to build my own (as I’ve done) or use what comes in the Microsoft box. Unfortunately in the case of AJAX the Microsoft currently is still in pre-release so for the moment I’m using my homegrown solution. The advantage with a homegrown solution is that I can tweak and adjust it and keep it light weight. And because I control it I’ve been building it to try and match some of ATLAS’ functionality to make moving the code in the future easier.

Framework Size

So, one of the most frequent concerns I’ve heard is the size of the ATLAS framework and the overhead that it is pushing over the wire. This is a valid concern for AJAX applications, but I think that ATLAS actually makes reasonable demands on the network for the functionality it provides.

The first complaint usually comes from the size of the massive client library which uncompressed is nearly 400k in size. With GZIP Web Resource compression which is provided as part of ATLAS  the base library hit compresses down to about 56k which is still pretty large – like the size of a large image. But remember that JavaScript libraries are cached so this is a onetime hit for a typical user on a site and given the feature set of that library I’d say a very worthwhile hit. Microsoft is also still working on optimizing the compression of the library so it may get smaller and more modular yet.

The next size issue is more important and is related to the use of UpdatePanel and the server controls in general. The ATLAS  server controls are based on the ASP.NET page pipeline so they sent up full POST data including ViewState and EventValidation and the server returns HTML fragments for any updateable regions of the page, plus ViewState and any script code the page or its controls generate. The size of the result varies depending on the size of the updated area of the page, but even if you were to retrieve a small portion of a large page chances are you’d be passing a significant chunk of the original page size over the wire. (example: www.west-wind.com/atlas/CustomerList/CustomerListUpdatePanel.aspx)

UpdatePanels are basically mini-page postbacks and you should treat them as such. If you’re building a frequently updating page that maybe has a timer on it and updates portions every few seconds on a heavily loaded site that may not be the best of ideas. But if you are dealing with more traditional page updates by clicking on link always keep in mind that while ATLAS UpdatePanel post backs may be large for typical AJAX solutions, remember that a full page postback without any AJAX would be larger yet and we’ve made do with that for years. In other words you’re still reducing the amount of traffic compared to a full post back.

But ATLAS also provides more low level and more efficient alternatives for making callbacks that send only the data you specify. You can for example, use client script code directly and use the server as merely a data service and pushing only a small of data back and forth between the client and server. The easiest way to do this is to use the Web Services bridge from client code which allows you with a few lines of script code to call server side ASMX Web service methods that return only the actual result data. ATLAS manages these Web Services calls for you by converting parameters and result values to and from JSON (JavaScript Object Notation) encoding and by providing proxy classes that make the remote service calls as easy as a single function call with a callback handler you specify.

But when the data returns at that point it becomes your responsibility to apply it to the page with JavaScript or the ATLAS client library, whereas with update panel the updating is handled automatically by the ATLAS framework.  But for high traffic scenarios low level access is definitely preferable (example: http://www.west-wind.com/atlas/Chat/Chat.aspx)

Which Approach is right?

I get a lot of questions in regards to which approach to use with ATLAS. Should we use UpdatePanels, or should we use low level functionality? How do you know which to chose? There’s no clear answer to this question and you have to weigh the benefits of each of the approaches. UpdatePanels are easy to use, but there’s significantly more overhead. Low Level access is more efficient but requires manually written client side code. Your application environment obviously has an impact too – are your users going to be using high speed connections or are there going to be many connecting with modems? Obviously this will affect your choice of tool.

But also consider that you don’t have to stick to one approach. You can mix and match various ATLAS features even on the same page. For example, you may have a page that requires rapid fire update requests to the server to provide some progress information, but to draw the final result as a data grid you might prefer to use an UpdatePanel to display the result using server logic rather than rendering the result on the client. (example: www.west-wind.com/atlas/LongProgress/LongProgress.aspx and www.west-wind.com/atlas/StockService/StockDisplay.aspx)

Mix and match functionality can provide the best of both worlds. Many folks want to avoid JavaScript altogether, but I think it’s vital to examine the application at hand and decide what works best. While writing JavaScript with the current crop of development tools is painful, many operations can be handled relatively easily. And once the client side ATLAS library gets some decent documentation, it can reduce some of the most painful aspects of dealing with browser incompatibilities. Unfortunately in its current state the client library is a bear to use as usable documentation and discoverability of the functionality is nearly non-existent.

If you’re going down the AJAX path, JavaScript is going to become a more important part of your development environment. This will get easier when Orcas arrives, but in the meantime we have to struggle with the existing tools. Investing some time getting acquainted with JavaScript should probably be high on your list of skills to acquire as a Web developer. Learning about JavaScript object orientation, prototypes, function pointers, closures (an excellent reference can be found here: jibbering.com/faq/faq_notes/closures.html) and a handful of other concepts specific to JavaScript is a prerequisite to use the ATLAS client library which uses some advanced concepts to provide abstraction and .NET like functionality.

We’re not quite there yet

Overall I think that ATLAS is hitting a pretty good balance between power and complexity, between size and flexibility. But even so there are a few things that I think that are problematic and hopefully some of these will be addressed before the 1.0 release hits.

UpdatePanels in particular have a few problems, mainly in that they can’t be easily controlled through client code. You can’t easily trigger an update panel from the client without creating phony event triggers (like adding a button an calling it’s click method to fire an update). You also can’t easily trap an UpdatePanel completion event so you can’t easily hook client code to the panel. While the focus on this control is for server side operation, being able to hook up client functionality comes in handy in many situations especially if you trigger the update panel through explicit code from the client and doing things like disabling and then re-enabling controls after a callback. This is not easily done today.

Another problem is the inability to keep an update panel from updating if an event is fired from within the panel itself. UpdatePanels have two supported update modes Always and Conditional, but even Conditional will update if you fire an event inside of the panel. This can be real problematic for some controls like listboxes or dropdowns that act as event triggers, but also need to be updated. Any click on the list will always force the panel to update, which is not the desired effect. But you may want to update the list after a change has been made to the data locally or after  timed refresh to get the latest data. There are no easy workarounds for this particular scenario.

Both of these are issues have been frequently requested on the ATLAS forums. If you take a look around the ATLAS forums (forums.asp.net/default.aspx?GroupID=34) you’ll find that there are quite a few quirks with UpdatePanels. Another one I’ve run into is that list controls will not fire the ItemCommand events in Conditional update mode. They only work in Always update mode. I’m not surprised at some incompatibilities to be honest – UpdatePanel is one heck of a complex control that has to handle any standard ASP.NET scenario based on pages and controls that never ever thought about the possibility of partial updates. So, realize that there are going to be some scenarios that just don’t work with UpdatePanel. Unfortunately it’s not even easy to pin down exactly what isn’t going to work or work slightly differently than it would in a post back. The most common things you have to watch out for are any dynamically injected scripts, headers, resources and attributes. Having initially hidden controls on a page and then making them visible in an update can also cause problems if the control needs to inject script or startup code.

There are lots of little issues that currently at least can break the perfect abstraction of “just slap an UpdatePanel around that control”.  The control is impressive and works in the most common scenarios, but be aware that there might be things that don’t.

I’ve also been thinking quite a bit about using ATLAS in custom control development but I’ve found that there’s currently no clear architecture to build ATLAS enabled controls. There’s the ATLAS Controld Toolkit – eh, Microsoft Ajax Control Toolkit, which provides a wizard and base framework, but it requires yet another external assembly. Natively the ATLAS library doesn’t provide a clear control design architecture and this seems to be a big missing piece at the moment. I foresee that ATLAS controls will be a combination of client control and server control and the two communicating with each other.

The most significant shortcoming is the lack of a standardized callback mechanism that allows you to make a callback to a user or custom server control. So if you build a custom control that needs to communicate with client JavaScript code for the client side portion of the control there’s no standard mechanism for doing that. While it’s easy enough to use the client library’s WebRequest object, there’s no standard protocol on the server to route the callback to a control and pick up the data from the client or even send it back in a standard way. I’ve actually used my home grown AJAX library (www.west-wind.com/tools/wwhoverpanel) to provide for this functionality in an ATALS application as it’s much easier than the native alternatives, but support for this should be baked into ATLAS natively.

We’re moving forward

Don’t let these quirks and issues discourage you though. Overall ATLAS feels very solid and we have to remember that it is still early in the release cycle. We’re not even in Beta yet and Microsoft has acknowledged a number of the shortcomings I’ve mentioned above and is considering to address them at some point. So things will only improve from here on out.

But AJAX technology is complex behind the scenes any way you look at it. AJAX and JavaScript is volatile – much more fragile than pure server script because there are so many things that can go wrong from lack of client support, to disabled JavaScript to network errors and browser incompatible code. It’s no surprise that we’re seeing so many Web pages these days (AJAX, ATLAS or just plain rich JavaScript client pages) that are popping up browser errors even on major sites. The browser is a tough platform to debug especially for code (as if HTML/CSS wasn’t hard enough <g>).

But AJAX technology is here to stay whether we like it or not, and it’s already having an impact on expectations for web site development. At the very least Microsoft has made building these types of applications with ATLAS relatively painless, and I think that the path they’ve taken is a good one in terms of providing the functionality that developers look for with a variety of different approaches that can be mixed to provide just the right kind of behavior.