The Ajax Papers
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,099
On Slideshare
2,099
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
33
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Ajax Papers Part I: The Intro and the Basics Ajax. We’ve all heard of it and most of us have already started to use it. Many of us (“us” being ASP.NET developers) probably decided to use Ajax because Telerik’s radAjax component made it very easy to add Ajax to our existing projects. We figured what the heck? Telerik makes it easy to add Ajax to my site and the boss will love to see the Ajax buzz word in my list of accomplishments. As radAjax developers, though, we often take for granted what’s actually happening under the proverbial Ajax hood. How does radAjax “auto-magically” make our pages do this Ajax thing? In fact, what really makes this Ajax thing work? These are questions that we’ll answer in my multipart series on Ajax. We’ll first establish firmly what Ajax is and how it manages to update a page without a refresh. Once we understand Ajax, we’ll look at radAjax and ASP.NET AJAX and discuss how they automatically ajaxify ASP.NET pages. With a solid foundation of Ajax and radAjax knowledge, we’ll move on to radAjax tips, tricks, and optimization techniques. Finally, we’ll wrap the series by looking ways to measure your Ajax page performance and compare radAjax enabled pages with pages ajaxified by the ASP.NET AJAX framework (including a preview of the new Manager for ASP.NET AJAX). When we’re done, you’ll be Ajax (and radAjax) experts capable of maximizing the benefits Ajax can provide in your application. What is Ajax? There are many books and articles out there explaining the 5Ws (Who, What, Where, When, Why) of Ajax, so I won’t spend much time on the history of Ajax in this series. I encourage you to read the Wikipedia article on Ajax or pick-up any book on Ajax from your local Barnes & Noble to get the full story. AJAX (Asynchronous JavaScript and XML) the term has been around for just two years (can you believe it?!), created by Jesse James Garrett in 2005. The technologies that make Ajax work, however, have been around for almost a decade. Trivia: So is it AJAX or Ajax? In Jesse Garrett’s original article that coined the term, it was AJAX. The “X” in AJAX really stands for XMLHttpRequest, though, and not XML. Jesse later conceded that Ajax should be a word and not an acronym and updated his article to reflect his change in heart. So “Ajax” is the correct casing. As its name implies, Ajax relies primarily on two technologies to work: JavaScript and the XMLHttpRequest. Standardization of the browser DOM (Document Object Model) and DHTML also play an important part in Ajax’s success, but for the purposes of our discussion we won’t examine these technologies in depth. 1|Page
  • 2. At the heart of Ajax is the ability to communicate with a web server asynchronously without taking away the user’s ability to interact with the page. The XMLHttpRequest is what makes this possible. This technology was created by Microsoft as an IE ActiveX control to support their (then) groundbreaking Outlook Web Access, but it has since been built-in natively to all modern web browsers (including IE7). In fact, if Mozilla had not had a rare “Microsoft moment” and decided not to add support for the non- standard XMLHttpRequest to their Firefox browser, it is doubtful that Ajax would be nearly as popular as it is today. How does Ajax work? So now you know that the XMLHttpRequest built-in to the browser makes Ajax possible, but how do web pages use this object and what does it really do? Glad you asked. This is where we first see JavaScript added to the Ajax equation, because to use the XMLHttpRequest on a web page we must write some JavaScript. The XMLHttpRequest, like any other JavaScript object, works because the browser’s JavaScript parser (or engine) recognizes the object in the code and knows how to process it. Trivia: Why is JavaScript (and in turn, Ajax) hard to write? In part, it is because every browser handles JavaScript just a little differently. Any web browser that wants to support JavaScript must provide its own engine to parse JavaScript commands and perform the correct browser actions. Firefox uses the open source JavaScript engine called SpiderMonkey, Safari uses an engine called JavaScriptCore, and Opera uses its own proprietary engine. IE’s engine actually processes “JScript", Microsoft’s own brand (Iiteraly) of JavaScript created (in part) to avoid copyright issues with JavaScript trademark holder Sun. Even though “JavaScript” is standardized by Ecma, each engine does things a little differently. That means solid JavaScript or Ajax programming must be done in a way that accounts for these differences. Aren’t you glad you use the Telerik magic now? Let’s start to put these ideas together in some code examples. The basic implementation of the XMLHttpRequest in JavaScript looks like this: //Get a reference to the XMLHttpRequest object var xmlRequest = (window.XMLHttpRequest) ? new XMLHttpRequest() : new ActiveXObject("Msxml2.XMLHTTP"); //If the browser doesn’t support Ajax, exit now if (xmlRequest == null) return; //Initiate the XMLHttpRequest object xmlRequest.open("POST", url, true); //Since this is a POST, set the request Content-Type header xmlRequest.setRequestHeader("Content-Type", "application/x-www-form- urlencoded"); //Setup the callback function 2|Page
  • 3. xmlRequest.onreadystatechange = function(){HandleAjaxResponse(xmlRequest);}; //Send the Ajax request to the server with the POST data xmlRequest.send(args); That’s it. That’s Ajax. Really. Any additional code you see is written to handle the response that the Ajax request returns (no small feat as we’ll see later). Trivia: How does ASP.NET AJAX do it? To examine the ASP.NET AJAX JavaScript in a readable format, simply open the MicrosoftAjax.debug.js file located in in your ASP.NET AJAX installation directory. Since Microsoft built a complete client-side programming model with the ASP.NET AJAX Extensions, the “Ajax” code in MicrosoftAjax.js is actually a small portion of its overal functionality. Nonetheless, we can find the Ajax code in the Sys.Net.XMLHttpExecutor client-side class (lines 3989 – 4267). The XMLHttpExecutor is actually executed by another ASP.NET AJAX class, Sys.Net.WebRequestManager. The XMLHttpExecutor is just one “Executor” that the WebRequestManager can handle. We’ll examine the ASP.NET AJAX code in more detail later in this series. In this example, we begin by creating a new instance of the XMLHttpRequest object: var xmlRequest = (window.XMLHttpRequest) ? new XMLHttpRequest() : new ActiveXObject("Msxml2.XMLHTTP"); We do this by first checking to see if the XMLHttpRequest object is natively built-in to the browser; if it’s not we assume we’re in IE and we create our XMLHttpRequest object using IE’s ActiveX component. If a browser does not support Ajax, the “xmlRequest” object will be null and our Ajax function will exit on the following line. Trivia: Msxml2.XMLHTTP vs. Microsoft.XMLHTTP If you look at different implementations of Ajax, you’ll notice that some use “Microsoft.XMLHTTP” and some use “Msxml2.XMLHTTP” when targeting IE’s ActiveX control. So what’s the difference? As it turns out, very little when written like that. While the “Microsoft” namespace is older than the “Msxml2” namespace, written like this both statements will target MSXML 3.0 (the most widely distributed version of MSXML). The latest version of MSXML, though, is version 6.0 (released July 2006). Vista ships with version 6.0 installed and it is available for download for XP, Win2k, and Win2k3. To target the latest and most secure version of MSXML, you must use “Msxml2.XMLHTTP.6.0” to create your XMLHttpRequest. Leaving the version number off on a system with 3.0 installed will always target MSXML 3.0 (even if 6.0 is installed). Go figure. Next we open our connection to the server with our newly created XMLHttpRequest object: xmlRequest.open("POST", url, true); 3|Page
  • 4. You must supply three parameters to the “open” method: 1. Request Method: either “POST” or “GET” (case sensitive). The “POST” and “GET” values should be familiar as they are normal Http concepts. Like normal Http requests, GETs are processed slightly faster by the server than POSTs, but they do not allow any data to be sent to the server (other than what you can fit into the URL’s querystring) 2. URL: the request URL (must be in your domain) 3. Async Flag: a Boolean value indicating if the request should asynchronous. That’s right. You can actually use the XMLHttpRequest to do SJAX (Synchronous JavaScript blah blah). This is rarely done for obvious reasons, so the third parameter in the “open” method will almost always be true. Important note: even though we’ve opened our connection at this point we have not yet sent our request to the server. Trivia: radAjax OnRequestStart and OnRequestSent The XMLHttpRequest’s “open” method fires just after the radAjax OnRequestStart client event. The OnRequestSent client event fires right after the XMLHttpRequest’s “send” method fires. Measuring the time between OnRequestSent and OnResponseReceived tells you exactly how long it took for your server to process and send your Ajax response. Since this is a POST, we then set the Content-Type header for the request: xmlRequest.setRequestHeader("Content-Type", "application/x-www-form- urlencoded"); If this were a GET request, we would not need to set the Content-Type here. You often hear the term “callback” replace the term “postback” when you work with Ajax. That’s because Ajax uses a “callback” function to catch the server’s response when it is done processing your Ajax request. We establish a reference to that callback function like this: xmlRequest.onreadystatechange = function(){HandleAjaxResponse(xmlRequest);}; The HandleAjaxReponse receieves a reference to our XMLHttpRequest object so that it can process the server’s response. OnReadyStateChange will fire multiple times during an Ajax request, so we must evaluate the XMLHttpRequest’s “readyState” property to determine when the server response is complete. A simple callback function may look something like this: function HandleAjaxResponse(xmlhttp){ //If readyState = 4, the server response is complete if (xmlhttp.readyState === 4) { //We can evaluate the status property to see what HTTP response code was returned //Status’ in the 200’s are okay; “200” is the best var statusCode = xmlhttp.status; if (statusCode < 200) || (statusCode >= 300){ 4|Page
  • 5. //Process the server response processResponse(xmlhttp.responseXML); }else{ //Some error handling processError(xmlhttp) } } } Trivia: HTTP Status Code 304 Http Status code 304 is technically a valid response code that could be returned from the server when performing a GET. It indicates that the page has not been changed and the page in the browser’s cache should be used. In Firefox, the XMLHttpRequest status property will return “200” if the server responds with “200” or “304”. IE will also return status code 200 in the XMLHttpRequest GET response, so a solid implementation of your callback function does not need to check for both codes. radAjax currently throws an error for any response that does not return code 200. The XMLHttpRequest has several properties that we’re interested in during our response callback function: readyState: indicates if the server is done processing our Ajax request. A value of “4” indicates the request is complete (true for all browsers). The number and values of the codes returned before “4” vary by browser, but the possible values are: o 0: uninitialized o 1: loading o 2: loaded o 3: interactive o 4: complete status: returns the HTTP response code sent by server for our Ajax request. A value of “200” means “OK” and that no errors occurred. Any other value indicates a situation that should be handled by our JavaScript Ajax error handler. responseXML: contains the XML formatted response from the server. This is actually an XML Document Object that can be parsed using XPath or regular DOM node tree methods (like getElementByTag, etc.). RadAjax primarily uses responseXML to process Ajax responses. responseText: contains the raw text response from the server If there is an error, we are also interested in this property: statusText: contains the text describing our response status code. If we receive a HTTP response code of “404”, for instance, the statusText would contain “Not Found”. 5|Page
  • 6. Trivia: JavaScript’s little know ‘===’ operator If you examine the ASP.NET AJAX JavaScript source code, you’ll see lots of “===” compare operators where you’d expect to find the normal “==” operator. Both will evaluate if an object is equal, but the “===” takes it another step further and validates that the objects being compared share the same identity. That means, in order for “===” to return true, the objects must be equal without JavaScript performing any data type conversions. This provides strict equality tests in JavaScript where loosely typed objects can often cause problems. And yes, “!==” exists, too. At this point we’ve sent our request to the server, received a response, and now we have an XML document object sitting in JavaScript memory. We’ve completed our asynchronous communication with the server, but now we need to update the page’s DOM. After all, the point of Ajax is to update the page without doing a full PostBack (and thus a full refresh) of the page. What should now be obvious is that the harder part of creating an Ajax application is implementing the code that parses the server response and updates the page; the communication is actually fairly straight forward and easy. What’s next? In the next part of our multi-part Ajax series, we’ll look at how JavaScript is used to parse our Ajax server response and update our page. We’ll see how DOM node tree methods and JavaScript are used to determine which parts of the page need updating and we’ll learn why it’s important to optimize our updated controls to get the most out of Ajax. So stick around, the best is yet to come. Todd Anglin, Technical Evangelist Telerik www.telerik.com References 1. Wikipedia, multiple articles, www.wikipedia.com 2. w3schools, The XMLHttpRequest Object, http://www.w3schools.com/xml/xml_http.asp 3. Sitepoint, Build Your Own AJAX Web Applications, http://www.sitepoint.com/article/build-your- own-ajax-web-apps/ 4. Adaptive Path, Ajax: A New Approach to Web Applications, http://www.adaptivepath.com/publications/essays/archives/000385.php 5. Web Master World, JavaScript Jumpstart – Operator Basics, http://www.webmasterworld.com/forum91/513.htm 6. Microsoft XML Team Weblog, Using the right version of MSXML in Internet Explorer, http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in- internet-explorer.aspx 6|Page
  • 7. The Ajax Papers Part II: Updating the Page In part one of this series on Ajax we looked at Ajax basics. What it is. How it works. Where it executes. We learned that Ajax communication (in its most basic form) only takes a few lines of JavaScript to work. If Ajax is so easy, what’s all the fuss about Ajax being so hard? Even though Ajax in its purest sense just defines a method for communicating asynchronously with the server, it is relatively useless unless you do something with the information returned from the server. That “something” usually means that you need to update portions of your web page with new HTML. And unlike Ajax communication, updating the page with new HTML after an Ajax callback is far from easy, especially when implemented in generic Ajax framework. In this installment, we’ll look at what it takes to update a page after an Ajax callback and what frameworks like RadAjax and ASP.NET Ajax do to make the process very easy for developers. Document Object Model (DOM) Just as JavaScript and the XMLHttpRequest are critical for Ajax communication, the ability to manipulate the browser’s document object model (or DOM) is critical for Ajax page updates. Most modern browsers support a standard interface to manipulate the browser’s DOM that can be programmed using JavaScript. There is nothing special about the JavaScript written for Ajax DOM updates (vs. any other DOM manipulation), but it can be tricky to determine which portions of your page need to be updated. Unlike PostBacks (which update the entire page), Ajax callbacks only update the portions of the page you programmatically update with JavaScript. That means you have to handle changes to all the page elements, the page head, the hidden page elements (like ViewState) and even the page title. Furthermore, since the page is not being reloaded, you also have to handle the execution of any page load JavaScript manually. You can see how this quickly gets tricky. Trivia: Why is manipulating the DOM hard? Every browser has its own JavaScript rendering engine and it has its own DOM layout engine. The W3C standardized the DOM in 1998, but browsers have been slow to provide uniform support of the W3C standards. Microsoft’s IE uses a DOM layout engine called Trident (or MSHTML), all Mozilla based browers (including Firefox and Netscape) use the open source Gecko layout engine, Safari uses Apple’s WebCore, and Opera uses its own proprietary Presto layout engine. All engines support DOM 1.0, but support for the later DOM 2.0 and 3.0 is still spotty. 7|Page
  • 8. Two Approaches for Updating the Page When it comes to updating the page after an Ajax callback, there are two basic approaches: 1) parse information from the server and build the updated controls on the client, or 2) build updated controls on the server and simply “swap” the old with the new on the client. The first approach can reduce the amount of information that is sent over the Internet during an Ajax update, but the savings is usually offset by the browser’s generally slow handling of DOM manipulations. Both RadAjax and ASP.NET AJAX take the approach of rendering the updated controls on the server and then removing the old controls and adding the updated controls on the client. There are some frameworks that parse XMLHttpRequest’s response to create the updated controls on the client (such as zumiPage), but for the most part Ajax libraries leave the heavy lifting on the server. Basic “Swap” Approach An Ajax library that is built to generically handle most page update scenarios (like RadAjax or ASP.NET AJAX) uses complex code to iterate through updated controls and perform the necessary client updates- more complex than we’ll look at in detail in this article. But the basic process of “swapping“ a control in the browser DOM is actually fairly simple. Let’s say we have a simple HTML input element on the page with an ID set to “lblTest”. Assuming we had code to extract the updated HTML from our XMLHttpRequest reponse, the first step would be to add the new control to the page, like this: if (nextSibling != null) { return parent.insertBefore(element, nextSibling); } else { return parent.appendChild(element); } Where “nextSibiling” and “parent” are relative to the old control and “element” represents the new control you are adding to the DOM. You add the new control before removing the old control to avoid the screen “flickering” in Mozilla browsers- in Opera you must remove before adding. That’s just one of the many nuances of working with the DOM in different browsers. After you’ve added your new control to the page, you can remove the old control like this: var parent = element.parentNode; if (parent != null) parent.removeChild(element); Where “element” is the HTML element you want to remove from the DOM. This approach works well in Mozilla browsers, but it can create serious memory leak problems in IE (go figure). To solve that problem, RadAjax uses a “garbage bin” approach to collect old controls and then dispose of them in a way that avoids IE’s memory leak problems. We’ll look at this method in more detail later. 8|Page
  • 9. Trivia: UpdatePanels vs. RadAjaxManager Unlike RadAjax, ASP.NET AJAX does not provide a control that allows you to define specific controls that should be updated as the result of an Ajax operation. Instead, ASP.NET AJAX relies on UpdatePanels (similar to RadAjax’s AjaxPanel) that update all controls inside of the UpdatePanel. For this reason, you won’t find any “parent.removeChild” or “.appendChild” code in Microsoft’s ASP.NET AJAX Libraries. What you will find is code like this: “updatePanel.innerHTML = updatedHtml;”, that replaces all of the HTML in an updated UpdatePanel with the server generated response. How Does RadAjax Do It? When you execute an Ajax callback using RadAjax (or any RadAjax based controls, such as RadGrid), the framework performs these major actions: Create New Fire OnRequestStart Show LoadingPanels XmlHttpObject Fire Fire OnRequestSent Send Ajax Request OnResponseReceived Update Controls Handle Response Fire OnReponseEnd HTML Scripts The step in this process that handles updating the page controls is obviously “Update Controls HTML”. If we look at the step in detail, we see it performs the following steps: Create Get old controls Update page head (if Hide loading panels HtmlContainer (to collection enabled) store new controls) For each control in Execute outside Update hidden Container replace scripts inputs old control with new control 9|Page
  • 10. Basically, RadAjax takes the collection of updated controls returned from the server (as defined in your RadAjaxManager or as contained in your RadAjaxPanel) and systematically removes the old version from the page and inserts the new version. To do this, RadAjax must know where a control is located on a page (determined by looking at an element’s parent and nextSibling). Optimizing your updates to minimize these page searches is one of the key ways you can improve your Ajax performance. Ajax Page Update Gotchas Browser Memory Leaks Browser memory leaks have always existed, but the advent of extremely complex client-side web applications that don’t rely on the traditional page navigation model to update the page have made memory leaks a problem that can’t be ignored. Just like .NET code, browsers have garbage collectors that are supposed to release memory from unused DOM elements (such as elements you remove from the page in an Ajax update). Certain coding patterns, though, can foil the browser garbage collectors and quickly turn your Ajax application into a memory hog. The most common coding practices that result in memory leaks are: Circular References, Closures, Cross-Page Leaks, and Pseudo Leaks. MSDN has a great article on memory leaks in IE and I encourage you to read it for a full understanding of these leak types (link in References list). This chart quickly highlights the frequency in which these leaks occur and their relative impact: Circular References •Most common •Large leaks possible •Type of circular reference Closures •Harder to spot •Very common when event handlers are bing used Cross Page Leaks •Persists across page navigations •Very small leaks Pseudo Leaks •Not really leak •Usually caused by misunderstood API The RadAjax framework takes special steps to make sure all DOM updates are done efficiently with the least possibility for memory leaks. Take a look at the JavaScript RadAjax uses to remove an element from the DOM: 10 | P a g e
  • 11. RadAjaxNamespace.DestroyElement = function(element) { if (AjaxNS.IsGecko()) { var parent = element.parentNode; if (parent != null) parent.removeChild(element); } try { var garbageBin = document.getElementById('IELeakGarbageBin'); if (!garbageBin) { garbageBin = document.createElement('DIV'); garbageBin.id = 'IELeakGarbageBin'; garbageBin.style.display = 'none'; document.body.appendChild(garbageBin); } // move the element to the garbage bin garbageBin.appendChild(element); garbageBin.innerHTML = ''; } catch(error) { } } You can see that a special garbage bin is used to remove controls from the IE DOM to prevent costly memory leaks. It’s this type of DOM optimization that makes Ajax frameworks invaluable tools when adding Ajaxifying our applications. Trivia: How do you fix a leaking IE? Knowing that browser memory leaks exist is great, but how do you figure out if your application is leaking? A great tool exists called Drip that enables you to easily obvserve any IE memory leaks your web application. Originally created by Joel Webber in 2005, Drip is now a SourceForge project that is freely available here: http://outofhanwell.com/ieleak. Even if you’re not concerned about fixing memory leaks in your application, it’s an interesting exercise to use Drip to see how efficiently your application uses system memory. In any event, just add Drip to that growing Ajax Batman-like bottomless toolbelt to improve your crime fighting code fixing skills for the future. ASP.NET AJAX, on the other hand, uses “dispose” expando methods on objects to handle memory leaks. The “dispose” expando is a method interface exposed by the ASP.NET AJAX client-side library that any custom object can implement and its purpose is to handle the removal of any attached events (or in other words, to remove anything that could cause a closure memory leak). When an UpdatePanel updates the page, it loops through all elements that will be updated and calls the “dispose” methods (if available) and then updates the HTML. This snippet shows you how ASP.NET AJAX UpdatePanels handle these dispose methods: 11 | P a g e
  • 12. function Sys$WebForms$PageRequestManager$_destroyTree(element) { if (element.nodeType === 1) { var childNodes = element.childNodes; for (var i = childNodes.length - 1; i >= 0; i--) { var node = childNodes[i]; if (node.nodeType === 1) { if (node.dispose && typeof(node.dispose) === "function") { node.dispose(); } else if (node.control && typeof(node.control.dispose) === "function") { node.control.dispose(); } var behaviors = Sys.UI.Behavior.getBehaviors(node); for (var j = behaviors.length - 1; j >= 0; j--) { behaviors[j].dispose(); } this._destroyTree(node); } } } } And just for complete understanding, here’s what a typical “dispose” implementation may look like: function Sys$UI$_UpdateProgress$dispose() { if (this._pageRequestManager !== null) { this._pageRequestManager.remove_beginRequest(this._beginRequestHan dlerDelegate); this._pageRequestManager.remove_endRequest(this._endRequestHandler Delegate); } Sys.UI._UpdateProgress.callBaseMethod(this,"dispose"); } Handling Response Scripts One thing you may have discovered when you started using Ajax is that the following ASP.NET code no longer works: Page.RegisterStartupScript("key","someScript();") Normally, that code snippet will render some JavaScript to the bottom of your page that will be executed when the page loads after a PostBack. When you use Ajax, the page no longer knows that it needs to update the HTML with this new JavaScript. Remember, with Ajax you have to tell the page about every item that needs to be updated and you have to manually execute dynamically added JavaScript. RadAjax provides an easy mechanism for getting around this issue. Instead of using the code above, you will write something like this: RadAjaxManager1.ResponseScripts.Add("someScript();") 12 | P a g e
  • 13. When you add your scripts to the RadAjax ResponseScripts collection, the RadAjax framework will make sure the scripts get executed after an Ajax callback by executing code like this: var newScript = document.createElement("script"); newScript.text = scriptCode; var scriptContainer = AjaxNS.GetHeadElement(); scriptContainer.appendChild(newScript); newScript.text = ""; I’ve omitted some of the cross browser and clean-up code for readability, but you get the general idea. The Ajax engine creates a new “<script>” element and executes your JavaScript. What’s next? In the next part of our multi-part Ajax series, we’ll examine in detail what is being sent over the pipe when we perform an Ajax Callback vs. a traditional ASP.NET PostBack. We’ll compare the difference in the HTTP request and response sizes and we’ll look at how RadAjax and ASP.NET Ajax handle different Ajax scenarios. In short, now that we know how Ajax communicates with the server and how it updates the page, we’ll try to quantify how much “value” Ajax updates have over postbacks. Until then, enjoy using your time saving Ajax framework of choice and go forward confident that you really understand what’s going on under the hood. Todd Anglin, Technical Evangelist Telerik www.telerik.com References 1. Wikipedia, multiple articles, www.wikipedia.com 2. Quirksmode, “Benchmark – W3C DOM vs. innerHTML”, http://www.quirksmode.org/dom/innerhtml.html 3. zumiPage, Homepage, http://www.zumipage.com/default.htm 4. MSDN, “Understanding and Solving Internet Explorer Leak Patterns”, http://msdn.microsoft.com/library/default.asp?url=/library/en- us/IETechCol/dnwebgen/ie_leak_patterns.asp 5. OutOfHanwell, “IE Memory Links”, http://outofhanwell.com/ieleak/index.php?title=Main_Page 6. Joel Webber Blog, “Drip: IE Leak Detector”, http://jgwebber.blogspot.com/2005/05/drip-ie-leak- detector.html 13 | P a g e
  • 14. The Ajax Papers Part III: Why, When, and What In parts one and two in this series on Ajax we examined in detail how Ajax communication works and how JavaScript is used to update the page after an Ajax callback. We looked at some of the specific ways RadAjax and ASP.NET AJAX handle Ajax operations and, in short, removed (or at least greatly reduced) the mystery of how these frameworks do their magic. In this installment, we’ll move past the “how” and “where” of Ajax and start to look at the “why”, “when”, and “what” (I don’t think we have any need to look at the “who”, so we’ll have to be satisfied with 4 of the 5 w’s). Why should you use Ajax in your web applications? When is it appropriate to use Ajax? When is it not? What is the real value of adding Ajax to your application? What are the drawbacks? To answer these questions we’ll start by looking at common scenarios on the web that have benefited greatly from the use of Ajax. Then we’ll explore when you should- and shouldn’t- use Ajax in your applications. Finally, we’ll wrap up by comparing the data that is sent over the Internet when you use Ajax callbacks instead of traditional page PostBacks to quantify Ajax’s value. Why use Ajax? Up to this point, we’ve assumed throughout this series that you actually need or want to use Ajax, no questions asked. And for many of us, that’s how we first added Ajax to our applications. We kinda knew what it was (we’d used Google Maps, after all). We knew RadAjax made it very easy to add Ajax to our applications. We knew it would make our applications “cool” and “Web 2.0-ish” (and impress the boss). So we embraced Ajax and ajaxified our applications without much more deep consideration for why we should use it. The most common benefits of Ajax are pretty easy to list: No more <insert negative adjective here> full page refreshes or PostBacks Enables responsive web applications that feel like Windows applications Reduces the amount of data that must be exchanged between the server and client While it is easy to measure how much bandwidth can be saved by using Ajax (which we’ll do later in this article), it can be much more difficult to quantify the benefits of “responsiveness” and “familiar UI”. Fortunately, many have already tried to address this challenge by conducting research to provide some level of expectation of the actual benefit derived from “soft” concepts like responsiveness and familiarity. 14 | P a g e
  • 15. One such attempt was made by Alexei White in an article titled “Measuring the Benefits of Ajax”. In that article, White explains how two identical applications- one built with traditional PostBacks and the other with Ajax- were tested by a handful of users while their bandwidth and productivity were measured. The results of White’s simple tests suggested the Ajax application (on average) improved bandwidth performance by about 70% and total task time by about 30%, which translates into over $10,000 in annual savings (based on an assumed 36 second improvement on a task completed 50,000 times in a year by a $20 per hour employee). Clearly, White’s research may not translate directly your application, but it does provide significant evidence that the simple process of ajaxifying your application can save your company (or clients) thousands of dollars. Trivia: Test your own ROI If you want to provide the ultimate “why” for adding Ajax to your application, perform your own Return on Investment (or ROI) tests. Using simple tools like Microsoft’s Fiddler (www.fiddlertool.com) to measure bandwidth and HTTP traffic and a stopwatch (the hold-it-in-your- hand-and-push-the-button variety) you can conduct your own tests with users to see how much time and bandwidth is saved when Ajax is used instead of PostBacks. Simply create a set of tasks for your users to complete and have them peform that set of tasks on the PostBack and Ajax-enabled versions of your application. Compare the results and apply this equation to come up with the “management friendly” number: Ajax Cost Savings = Hourly Labor Rate * ((Seconds Saved Per Transaction * Transactions Per Year)/3600) Furthermore, with RadAjax in your toolbox, there are even more reasons to add Ajax to your web application: It’s very easy to ajaxify your application (no code changes necessary) It’s very easy to remove Ajax from your application if you don’t like it You have Best in Class support to help you solve your Ajax problems So whether you added (or are going to add) Ajax to your web application because you thought it was “cool” or because you measured the potential ROI like Alexei White, there should be no doubt that Ajax (even simple implementations) can add lots of value your project. When you should use Ajax With tools like RadAjax and ASP.NET AJAX, it is not hard to find places in your application that can benefit from instant ajaxification. In general, any UX (short for “user experience”, a more holistic approach than “user interface” or UI) in your application that does not involve navigation is a good candidate for Ajax. Common examples of these interactions are: A form that validates values with some server process A drop down list that loads values in response to another element’s action 15 | P a g e
  • 16. Voting or rating input elements Multi-tab interfaces Any grid operations (such as sorting, selecting, editing, filtering, etc.) It is important that you identify actions in your application that can be ajaxified at a very granular level. In other words, if you have a page on which most of the contents are updated after a PostBack, applying Ajax to the page will not provide much (if any) benefit. Remember from our earlier examination of Ajax in part’s one and two of this series that Ajax is good at quickly updating small portions of the page. If you apply your ajaxification too broadly, you’ll lose many of the underlying benefits. Let’s look at a practical example. Let’s say we have page that conceptually looks like this: Page Header Content Navigation asp:Panel Misc. Label Details View Grid Treeview controls Footer If we decide to ajaxify all of the actions on this page that normally use PostBacks, we might be tempted (especially if we’re using ASP.NET AJAX UpdatePanels) to simply ajaxify the “asp:Panel”. After all, that would automatically convert any action from the Treeview, Grid, or the Details View into an Ajax Callback and allow those actions to update any of the other controls in the Panel. Doing that, though, would probably eliminate most of the value we could extract from Ajax. Instead, we should focus on defining Ajax interactions that update the fewest elements on the page as possible. For instance, if our Grid has an event that updates the Details View, our goal should be to create an Ajax action that updates only the Details View and leaves all other controls (including the Grid) untouched. If our Treeview loads nodes from the server as it is expanded, we should only update the Treeview and no other control on the page to maximize our Ajax benefits. The RadAjax Manager from Telerik (and the soon to be released Manager for ASP.NET AJAX from Telerik) makes it very easy to define these granular relationships and use Ajax in a way that adds value to your projects. When you shouldn’t use Ajax Ajax is so easy to add to applications these days, it is just as important that you know when not to use it as it is to when to use it. While it improves many page interactions, the overhead and complexity that Ajax can introduce to a page sometimes outweighs the potential benefits. 16 | P a g e
  • 17. To understand when you shouldn’t use Ajax, it is important that you understand some of the problems Ajax introduces into otherwise working applications: Back button breaks This is probably one of the biggest challenges for applications that were not designed with Ajax specifically in mind. Usability gurus will tell you that the most used feature of any modern Internet browser is the back button and any application that breaks it should be considered “unusable”. Applications designed for Ajax overcome this limitation by using special tricks to populate a browser’s History (thus re-enabling the back button) or by adopting a single-page model that breaks the users “I need to go back” thought process. Users cannot bookmark pages If you’re foolish enough to use Ajax for a site’s navigation (which I obviously recommend against, unless you’ve fully adopted the single-page application model), Ajax will also make it impossible for users to bookmark pages in your application. Server errors get lost Not properly handled with client-side code, unexpected server responses during Ajax operations can result in the appearance of a “hung” application. Sometimes extra consideration must be made when moving from PostBacks to Ajax to properly redirect your users when an error occurs. Longer initial page load time If you think Ajax is designed to make your initial page load time faster, you’re wrong. By its very nature, Ajax will likely increase your initial page load time since it must load client libraries (JavaScript files) to handle all of the Ajax operations. This impact is usually relatively small when weighed against the improved responsiveness on subsequent Ajax requests, but if your page is relatively simple and the Ajax is providing relatively little value you may want to consider if the page load penalty is worth it. (To be fair, browser caching makes this less of an issue if you have other pages in your application that use the same Ajax libraries, but something to consider nonetheless.) Search index problems If you decide to use Ajax to load content in your application that may have previously been loaded on the initial page load (for instance, ToolTip content), remember that search indexers will not be able to see or index that content. That means you need to be careful about using Ajax on content that is key to your search indexing or you need to add code that automatically recognizes a search engine crawler and serve a version of your page that includes the Ajax content. Browser feedback breaks When you use PostBacks, users know the page is doing something when they see the little loading graphic spinning in their browser. When you use Ajax, this critical feedback that the page is working disappears. Fortunately, products like RadAjax make this an easy problem to solve with easy to use LoadingPanels that take the place of the browsers progress indicator. 17 | P a g e
  • 18. Obviously, you shouldn’t rush into adding Ajax to your application until you understand fully how each of these issues could potentially affect your application’s performance and usability. You should always make sure you have a good reason for adding Ajax to your application (or page) and never add it simply because it looks cool. If you do, you may end up running into one of these problems unexpectedly and creating more trouble than necessary. Trivia: Fixing the back button There are several different ways you can fix the browser back button on Ajax-enabled pages. The two most popular methods are the “hidden iFrame hack” and the “window.location” hack. Each method has drawbacks (for instance, the iFrame hack doesn’t work in Safari 2.0 and the window.location hack doesn’t have full support IE), but they can help you restore some level of back button support to your Ajax applications. Several libraries exist that give you easy access to these hacks, such as the Really Simple History (or RSH) JavaScript library that is designed specifically for this task. If you’re using ASP.NET AJAX, Nikhil Kothari has created an “UpdateHistory” control that enables you to (more) easily handle the task of selectively populating the browser’s history and thus re-enabling the back button. We will cover some of the back button hacks in detail in a future installment in this series. What is the difference: PostBack vs. Callbacks Here is where the rubber meets the road. So far we’ve assessed in general terms why and when you should use Ajax, but all of that is empty rambling if Ajax does not really improve your page performance in a measurable way. To prove that Ajax makes a meaningful difference, we’ll examine the bandwidth used and responsiveness of a sample web page in three different scenarios: 1. Traditional PostBacks for all operations 2. RadAjax to ajaxify all operations 3. ASP.NET AJAX to ajaxify all operations The Test To conduct our test we’ll use a real world site: converter.telerik.com. This online code converter from Telerik allows people to easily convert VB to C# and C# to VB, and it is a perfect place to put our scenarios to the test. Tests will be run by pasting a C# code snippet into the Code Converter and then clicking the “Convert Code” button. Using IE 7 and Fiddler, we will measure the size (in bytes) of the request and response for each conversion, and we clear the browser cache before each set of tests. The test will be run for each of our three scenarios, resulting in 18 data points (page load + 5 clicks for each scenario). Since this is a single step process, measuring actual time savings will be difficult. To measure time savings in your own tests, you should design a test with multiple steps and try to find several users that 18 | P a g e
  • 19. you can time as they complete the steps of your test. We don’t have that luxury for this paper, so we’ll be focusing on primarily on the bandwidth savings Ajax provides (or does it?). The Results After running all of our tests, logging the results, and then averaging the request and response bytes for each scenario (PostBack, RadAjax, and ASP.NET AJAX), we discover that Ajax does in fact deliver a huge bandwidth savings over traditional PostBacks (see chart below). In the case of our Code Converter, the act of simply switching from PostBacks to RadAjax callbacks (which we can do without writing any code…but that’s another demo) reduced our average response size by over 65%! If we look at the average response size after the first response (in other words, after most JavaScript files have been cached), the improvement made by RadAjax is just shy of 90%. That means the server has to send 90% less data over the Internet and the user has to wait on 90% less data to arrive when the Code Converter uses RadAjax instead of PostBacks. Average Request/Response Bytes After Cache Response After Cache Request PostBack Response RadAjax AspNetAjax Request 0 50,000 100,000 150,000 In business terms, this experiment tells us that Ajax is a real money saver. Let’s say the Code Converter processes 1000 conversion requests a day and that the full PostBack response size of those pages is about 200KB. In a month’s time, the Code Converter could burn through 6GB of bandwidth with traditional PostBacks. By implementing Ajax, though, we can cut that number to just 600MB. Scale that out for larger and more popular sites and you can see how the savings really start to add up (especially for the users on the other end of that number, waiting for the response to download). The comparison of RadAjax to ASP.NET AJAX, on the other hand, was fairly equal. While the average ASP.NET AJAX response size with the “first request penalty” (before caching) was 46KB and the RadAjax 19 | P a g e
  • 20. response was about 51KB, the subsequent “post cache” responses were 19KB and 16KB on average respectively (see figures below). The perceived responsiveness of ASP.NET AJAX and RadAjax were the same for this test, but the RadAjax implementation was much easier to configure and add to the application. Page Size by Content Type and Scenario Fig 2.1: No Ajax, original page request (164KB) Fig 2.2: No Ajax, PostBack response (146KB) Fig 3.1: RadAjax, original page request (223KB) Fig 3.2: RadAjax, Callback response (16KB) Fig 4.1: ASP.NET Ajax, original page request (179KB) Fig 4.2: ASP.NET AJAX, Callback response (29KB) These charts highlight some interesting facts about Ajax. First, as I asserted earlier in this paper, Ajax does not make the page smaller on the first uncached request. In fact, we can see both of the Ajax enabled pages are noticeably larger (8% for ASP.NET AJAX and 27% for RadAjax). We see that Ajax’s real benefit is in the subsequent page response size, which leads us to interesting fact number two. Look at what’s missing from the second RadAjax and ASP.NET AJAX charts. There are no HTML, image, or CSS “slivers” in those responses (unlike the PostBack response). And even though there appears to be more JavaScript, we can tell by the total response size that the majority of the JS being returned in the PostBack response has been cached in the Ajax responses. 20 | P a g e
  • 21. These tests clearly make the case for Ajax in the Code Converter website. While your tests may not produce numbers that look exactly like these, you should find that the general conclusions and comparisons remain true. At the end of the day, the take away from these tests should be: RadAjax and ASP.NET AJAX offer relatively similar performance Regardless of which Framework you use, Ajax definitely provides significant, measurable benefits over PostBacks. Trivia: The ViewState Burden It’s not secret in ASP.NET development that ViewState can quickly double (or more) the size of a page. In the past, developers have often had to accept this or find creative ways to move ViewState off of the page to avoid the size penalty while still being able to maintain state across PostBacks. When you use Ajax, though, you have new opporunities to disable ViewState altogether. Ajax callbacks do not refresh the whole page so the state of most controls is natrually preserved. By eliminating ViewState you can further reduce the size of your Ajax request and response sizes, often realizing improvements of over 50%. In a simple test conducted with a RadGrid and ASP.NET Panel, Ajax response sizes were decreased from 24KB to 5KB by disabling ViewState and using client-side code instead of server-side updates to update the appearance of the Grid. Designing for Ajax We’ve spent a lot of time talking about how you can convert existing ASP.NET applications to Ajax- enabled applications in this paper, but we haven’t addressed the scenario in which you design your application from the ground up with Ajax in mind. If you have the luxury to design your application from scratch, there are definitely lots of new interaction models that Ajax enables you to use. With Ajax and a powerful set of UI controls (like Telerik’s RadControls for ASP.NET), you can replicate almost any desktop interaction model on the web, in all of the major browsers. The benefits of modeling a web application after a desktop application often manifest in the form of reduced training and support costs. Users’ expectations for how interfaces should work are still largely influenced by the time they spend on the desktop, especially by programs they use often (like Microsoft’s Office). If you can provide experiences on the web that support those expectations, you will have to spend less (not no) time training your users and your users will likely be much more productive in a shorter period of time. The reason I often glide past this approach to web application design in these papers is because it is still hard for many experienced web developers to think in the new terms of designing web applications that feel like desktop applications. We have become so used to the multi-page, form element model of designing pages that we simply overlook opportunities to embrace a single-page application model that uses Ajax to support context menus, menu bars, and the like. If you do step back, though, and design an 21 | P a g e
  • 22. application that maximizes the power of Ajax, you can definitely create applications that do much more with Ajax than simply turning PostBacks into Callbacks. Trivia: Designed for Ajax If you found this section to be more “rah, rah, Go Team” than fits your fancy, check out some sites that have fully embraced Ajax from their inception to see exactly what Ajax enables. A great example is PageFlakes.com. Built completely on ASP.NET AJAX, Page Flakes is a perfect example of how you can use an Ajax Framework (vs. custom Ajax code) to implement a unique PostBack-less interface. Also a good example is Yahoo! Mail, which replicates the feel of a desktop mail client in the browser. While it runs on Yahoo!’s own Ajax framework, the site is still a good example of how new web technologies (and wide browser support) enable previously unthinkable interactions on the web. And with tools like RadAjax, you don’t have to be a mult-million dollar company or have hundreds of hours to implement them! What’s next? Coming up next, we’ll shift our focus away from a general study of Ajax and begin to look at ways you can specifically optimize RadAjax in your applications. At this point you should have a complete understanding of what’s going on under the hood of RadAjax and have a sense for the kind of measurable value Ajax can provide. Now it’s time to take that knowledge and unleash it on RadAjax to squeeze out the maximum performance gains. As I near the end of this series, though, I want to make sure I’ve addressed all of your unanswered questions about Ajax and RadAjax specifically. If I’ve missed something along the way that you’d like to know more about, please email your questions to me at todd.anglin[at]telerik.com. If I receive enough questions, I’ll do a special “open mic” installment of the Ajax Papers where I answer your questions. Until then, have fun testing your own applications and telling your bosses how much money you’re going to save the company by adding Ajax to your next project! Todd Anglin, Technical Evangelist Telerik www.telerik.com References 1. White, Alexei. Developer.com. “Measuring the Benefits of Ajax”. http://www.developer.com/java/other/article.php/3554271 2. Bosworth, Alex. SourceLabs.com. “10 Places You Must Use Ajax”. http://www.sourcelabs.com/blogs/ajb/2005/12/10_places_you_must_use_ajax.html 3. ASP.NET AJAX. General use. http://ajax.asp.net 22 | P a g e
  • 23. 23 | P a g e