A few weeks ago Microsoft announced new naming for the product formerly known as Prince-uh, 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 hall 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 the ATLAS CTPs currently support. Microsoft will provide the remaining controls 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 Microsoft wants 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 who prefer not to run with non-release software. 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. Microsoft will provide tool support 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. Visual Studio “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. However, the final release of this next version of Visual Studio is a long ways off. Microsoft has hinted at a projected release at the end of next year, but given the scheduling delays Microsoft developer tools have been going through for the last few major release cycles, don’t consider getting improved tool support for your Microsoft AJAX applications any time soon.
Where Are We Now?
ATLAS has come a long way since the first presentations that Shanku Niyogi and Nikhil Kothari gave at PDC about a year ago. I remember sitting in those sessions, feeling both excited and massively overwhelmed. I also remember looking around the room at a bunch of shell-shocked faces of individuals who appeared to feel the same way. There was excitement, but also a lot of trepidation about the complexity, sheer size, and functionality of what the 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 code 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 in order to use the technology effectively. However, 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 five-minute walkthroughs from the ATLAS Web site. You’ll have to do the same if you plan to build ATLAS-enabled controls. Microsoft hasn’t provided a clear path to building ATLAS-enabled controls that have both client and server components. 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 shown at PDC. To some extent, Microsoft changed ATLAS based on community input. Immediately following PDC, Microsoft released a very rough preview as a work in progress and looked to the community for input on various forums to see how people applied the technology. Microsoft pulled some features, downplayed others a bit (XMLScript for example), and Microsoft improved some features 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, Microsoft has released only Community Technical Previews (CTPs), which means ATLAS is still a pre-release, pre-beta product. However, the last few releases have been fairly stable without much feature creep. It’s been nearly two months since the last CTP in July so it looks like they’re doing a lot of work 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 of ATLAS 1.0 is pretty optimistic, given that there are still a number of open issues, especially in the server controls, that Microsoft hasn’t adequately addressed, and with three months until the end of the year it seems that time is getting short. I’d prefer a solid first beta 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 you can use today in your applications.
I am still convinced that most Web applications can operate just fine without AJAX technology and if they do use it, those sites can and should use it judiciously to provide additional functionality to the application. In the right situations AJAX can provide definite practical advantages and I’ve focused on that. I always ask people how they intend to use AJAX functionality in their applications and very few have a good idea about how to apply the technology. AJAX doesn’t fit everywhere and I think it’s certainly not the new paradigm that some people suggest it is.
It’s interesting to see how the expectations of what AJAX is and how it should work seems to polarize developers into two clear camps: those that want a very lightweight mechanism to call server functionality, and those that just want a very easy mechanism to work with AJAX.
ATLAS actually addresses both of these scenarios rather well, but I’ve been surprised that there’s a lot of resistance to ATLAS. 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 lightweight than ATLAS. Popular other choices include 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 also use 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 seems like an elephant in a porcelain store.
So why bother with ATLAS? If you have something that works well for you, and you are comfortable with the tool, consider sticking with your existing solution. There may be technical reasons to move to ATLAS, but more likely the reasons will 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 I must either build my own (as I’ve done) or use what comes from Microsoft. Unfortunately, in the case of AJAX, Microsoft’s current AJAX offering is still pre-release and so I have to use a homegrown solution. One advantage of the homegrown solution is that I can tweak it to keep it lightweight and I’ve been building it to try and match some of ATLAS’ functionality to make moving the code in the future easier.
Framework Size
One frequent concern I’ve heard is the size of the ATLAS framework and its overhead. This is a valid concern for AJAX applications, but I think that ATLAS 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 is nearly 400KB in size when uncompressed. With GZIP Web Resource compression, which Microsoft provides as part of ATLAS, the base library hit compresses down to about 56KB. That’s about 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, so I’d say a very worthwhile hit. Microsoft is also still working on optimizing the compression of the library so it may become smaller and more modular. The unofficial word from Microsoft is that the download size is going to shrink to somewhere around 10KB with full compression.
A more important issue is related to the use of UpdatePanel and the server controls in general. Microsoft based the ATLAS server controls on the ASP.NET page pipeline so they send up full POST data including ViewState and EventValidation. The server returns HTML fragments for any updatable 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 build a frequently updating page on a heavily loaded site that has a timer and updates portions every few seconds, that may easily create a heavy load on the server due to all the network traffic. But if you are dealing with more traditional pages that update when users click on links, keep in mind that while ATLAS UpdatePanel postbacks may be large for an AJAX solution, a full-page postback that doesn’t use AJAX would be larger yet. In other words, you’re still reducing the amount of traffic compared to a full postback.
ATLAS also provides more low level and 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, pushing only a small amount 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 to call server side ASMX Web service methods that return only the actual result data with a few lines of script code. 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.
When the data returns it becomes your responsibility to apply it to the page with JavaScript or the ATLAS client library, whereas with UpdatePanel the updating is handled automatically by the ATLAS framework. 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 you use UpdatePanels or should you use low-level functionality? How do you know which to choose? 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-will your users use high speed connections or will many connect 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 Microsoft provides some decent documentation for the client-side ATLAS library, 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 because usable documentation is nearly non-existent and it is difficult to discover its functionality.
If you’re going down the AJAX path, JavaScript will become an important part of your development environment. This will get easier when Visual Studio “Orcas” arrives, but in the meantime we have to struggle with the existing tools. A Web developer who wants to use ATLAS should invest some time getting acquainted with JavaScript. Learning about JavaScript object orientation, prototypes, function pointers, closures (you’ll find an excellent reference at 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. However, there are a few things that I think are problematic and hopefully Microsoft will address some of these before the 1.0 release hits.
UpdatePanels in particular have a few problems, mainly that you can’t easily control them through client code. You can’t trigger an UpdatePanel from the client without creating phony event triggers (like adding a button and calling it’s Click method to fire an update). You also can’t trap an UpdatePanel completion event so you can’t easily hook client code to the panel. While Microsoft really designed this control for server side operation, being able to hook up client functionality comes in handy in many situations. For example, you might trigger the UpdatePanel through explicit code from the client and then disable a control, fire the update, and then re-enable controls after the callback. This is not easily done today.
Another problem is the inability to keep an UpdatePanel 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 problematic for some controls like list boxes or drop-downs that act as event triggers, but also need to be updated. Any click on the list will force the panel to update, which is not the desired effect. You may want to update the list after a user changes the data locally or after a timed refresh to get the latest data. ATLAS doesn’t offer an easy workaround for this particular scenario.
Developers have frequently raised both of these issues on the ATLAS forums. If you read the ATLAS forums (forums.asp.net/default.aspx?GroupID=34) you’ll find that users have noted quite a few quirks with UpdatePanels. In addition, I’ve found 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-UpdatePanel is one heck of a complex control that has to handle any standard ASP.NET scenario based on pages and controls that were not designed with the possibility of partial updates. Because of this, there are going to be some scenarios that just don’t work with UpdatePanel. Unfortunately it’s not easy to pin down exactly what isn’t going to work or will work slightly differently than it would in a postback. You do want to watch out for common things including dynamically injected scripts, headers, resources, and attributes. If your page has initially hidden controls on a page and then you make them visible in an update, that can also cause problems if the control needs to inject script or startup code.
Currently there are lots of little issues that 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 work.
I’ve thought quite a bit about using ATLAS in custom control development but I haven’t found a clear architecture to build ATLAS-enabled controls. The ATLAS Control Toolkit-uh, Microsoft Ajax Control Toolkit-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 so I think Microsoft is clearly missing something important at the moment. I foresee that Microsoft will make ATLAS controls a combination of client controls and server controls that communicate with each other.
Another significant shortcoming is that ATLAS lacks a standardized callback mechanism to allow 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 you can easily 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 created this functionality in my home-grown AJAX library (www.west-wind.com/tools/wwhoverpanel) in an ATLAS application because it’s much easier than the native alternatives, but I think Microsoft should bake this support into ATLAS natively.
We’re Moving Forward
Don’t let these quirks and issues discourage you. Overall ATLAS feels very solid and remember that it is still early in the release cycle. ATLAS is not even in beta yet and Microsoft has acknowledged a number of the shortcomings I’ve mentioned above. So things can only improve from here on out.
AJAX technology is complex behind the scenes any way you look at it. AJAX and JavaScript are volatile-much more fragile than pure server script because there are so many things that can go wrong including lack of client support, a browser that has disabled JavaScript, network errors, and code that isn’t compatible with a particular browser. It’s no surprise that you see so many Web pages these days (AJAX, ATLAS or just plain rich JavaScript client pages) that pop 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>).
Whether you like it or not, AJAX technology is here to stay and it’s already having an impact on expectations for Web site development. At the very least, Microsoft will make building these types of applications with ATLAS relatively painless. 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.
