Atlas: Think before you lift |
 |
By Mike Gunderloy, Contributor
02 May 2006 | SearchVB.com |
|
|
In classical mythology, Atlas bore the weight of the heavens and the earth on his back. If you don't want to share his fate, you should be at least a bit careful about deploying the new ASP.NET "Atlas" technology that Microsoft has been trumpeting lately. Although it's bright, shiny, and state-of-the-art, it's also pre-release and not right for every project. So before you pick up that globe and start lifting, take a few minutes to understand what you're picking up and why you might want to use it.
You've probably already heard the pitch for Atlas and other Ajax (Asynchronous JavaScript and XML) libraries: a richer client-side Web experience, more responsive Web applications (because more of the work is being done on the client instead of the server), a more modern look for your applications. That's all true and it's all great.
But what about the dark side of Atlas? As with most other things in the development world, there's no free lunch.
For starters, there's that whole JavaScript thing. Getting all the Atlas magic to happen takes a fair chunk of JavaScript -- over half a megabyte in the uncommented release version. All that has to get to the client browser, so even though things are speedy after it's there, the first load experience may not be so hot on slow connections. There's also the issue of debugging: just how much do you trust this code? How are your skills for reading and understanding JavaScript? Are you willing to just accept it as a black box that you never touch?
Then there's the whole issue of cross-browser compatability. Atlas works great in Internet Explorer and Firefox. Right now Safari gives it fits. And even if Safari support gets fully implemented in the release version (which seems potentially unlikely, given some architectural limits), there will undoubtedly be some browsers where this stuff just doesn't work. For intranet sites where you're in control of the browser version, that may not matter. But if you're deploying to the wider Internet, you have to ask yourself what your strategy for dealing with those other browsers is. Do you spend time programming alternate versions of features that depend on Atlas? Do you just tell people using other browser that they're out of luck? What portion of your customers can you afford to alienate?
Worse than cross-browser compatability, though, is cross-library compatability. Unless Atlas is the only bit of JavaScript on your pages, you need to worry about whether using it will break other things. Don't be too sure you're not already using JavaScript, either. Have you installed any third-party controls on your site? Perhaps a fancy calendar? Maybe you've used some fancy alternatives to tbe built-in validation controls? Many fine ASP.NET products include bits of JavaScript under the hood. Atlas does a lot of low-level manipulation of the browser to implement its functionality, and it can and does break other things. There's no cure for this if it happens to you. You just get to decide whether you'd rather have Atlas, or dump it the get back the other control.
Finally, you'll notice I said "release version." In case you missed it, despite all the hoopla Atlas is still pre-release as of this writing. Which means, of course, that anything you develop using the current version will quite possibly need to be redeveloped, or at least tweaked, when the final version comes out. It's all very well to be the first one out of the gate with new technology, but you need to allow time in your schedule for the nearly-inevitable rework.
Now, all that aside. Do I think using Atlas is a good idea? Heck yes -- for some sites. When you have a site that can really benefit from client-side techniques such as confirmation dialogs and collapsing panels, and you can come up with a good way to "gracefully degrade" the experience for browsers that don't support Atlas, when your schedule allows the time for testing and potential rework -- go for it! Just don't treat this, or any other, technolgy as magic pixie dust that you can sprinkle on your applications to make them instantly better without any potential drawbacks.
Mike Gunderloy is the Senior Technology Partner for Adaptive Strategy, a Washington State consulting firm. You can read more of Mike's work at his Larkware Web site, or contact him at MikeG1@larkfarm.com.
|
|
|
|
