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.
Where are we at?
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.
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 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.
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)
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.
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 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.
Other Posts you might also like