Encosia » jQuery

Hear me talk jQuery and ASP.NET on the jQuery Podcast

Dave Ward — Mon, 30 Aug 2010 15:10:36 +0000

Last week, Ralph Whitbeck was kind enough to have me as a guest on episode #32 of the jQuery Podcast. We spoke about topics including:

Research I’ve done on the public CDNs that host jQuery, and why it matters which one you choose
Why you should never use a "latest version" reference to scripts on those public CDNs
The drawbacks of always waiting on $(document).ready()
My video tutorial series, Mastering jQuery

I really enjoyed talking with Ralph, and I think the episode turned out great. You can listen to it at: http://podcast.jquery.com/2010/08/27/episode-32-dave-ward/

You've been reading Hear me talk jQuery and ASP.NET on the jQuery Podcast, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

Don’t let jQuery’s $(document).ready() slow you down

Dave Ward — Wed, 18 Aug 2010 17:26:56 +0000

jQuery’s $(document).ready() event is something that you probably learned about in your earliest exposure to jQuery and then rarely thought about again. The way it abstracts away DOM timing issues is like a warm security blanket for code running in a variety of cold, harsh browser windows.

Between that comforting insurance and the fact that deferring everything until $(document).ready() will never break your code, it’s understandable not to give much thought to its necessity. Wrapping $(document).ready() around initialization code becomes more habit than conscious decision.

However, what if $(document).ready() is slowing you down? In this post, I’m going show you specific instances where postponing startup code until the document’s ready event slows perceived page load time, could leave your UI needlessly unresponsive, and even causes initialization code to run slower than necessary.

Example: live()

One of the most popular uses for jQuery’s live() is to maintain event handlers on elements that are dynamically created and destroyed over time. Instead of juggling traditional bind() handlers in response to those changes, live()’s event delegation allows you to declare handlers once up-front. Whether targeted elements exist at declaration time, or in the future, one live() handler will apply to them all.

Imagine that we have an application with several slideToggling sidebar blocks which may be dynamically added and removed while the user interacts with the page. You’ve probably seen live() used like this to simplify handling those future changes:



   type="text/javascript" src="jquery.js"></script>
   type="text/javascript">
    
    $(document).ready(function () {
      $('#Sidebar h3').live('click', function () {
        $(this).next().slideToggle();
      });
    });
  


   id="Sidebar">
    Title 1
    Text 1
 
    Title 2
    Text 2

That usage is natural when you’re hedging against AJAX-driven changes in the future. The volatility that you’re concerned with won’t happen until after the page loads, so it’s intuitive to postpone worrying about them until after the document’s ready event.

However, what would happen if you treated your HTML document’s initial load process the same way as any other dynamic modifications?



   type="text/javascript" src="jquery.js"></script>
   type="text/javascript">
    
    $('#Sidebar h3').live('click', function () {
      $(this).next().slideToggle();
    });
  


   id="Sidebar">
    Title 1
    
    Text 1
 
    Title 2
    
    Text 2

Not only does that work just as well as postponing the live() declaration until the document’s ready event, but now the handlers are active during the page loading process. As the browser loads each

element and adds it to the DOM, our click events are immediately ready to be handled.

Benefit: A more responsive UI

To see where the latter approach shines, imagine the page was very large and took several seconds to load, or that a script reference somewhere on the page was timing out. In scenarios like those, jQuery’s document ready event may not fire until considerably later than the targeted elements are visible to your users.



   type="text/javascript" src="jquery.js"></script>
   type="text/javascript">
    
    $('#Sidebar h3').live('click', function () {
      $(this).next().slideToggle();
    });
 
    
    $(document).ready(function() {
      $('#Sidebar p').live('click', function() {
        // Important magic goes here.
      });
    });
  


   id="Sidebar">
    Title 1
    Text 1

src="http://twitter.com/fail-whale.js"></script>

Why hold live() back until the document is ready? It doesn’t matter if the selector matches any elements initially; they will immediately become active as they are rendered and appear on the page.

Benefit: Improved performance

A common criticism of using live() for event delegation is that it requires you to perform an initial selection of all of the elements that it targets. Since event delegation doesn’t require any initial setup on each individual element, this pre-selection is a wasteful performance drag when there are dozens or hundreds of elements targeted.

However, if you register your live() handlers before those elements exist on the page, there is no performance penalty whatsoever. The event delegation can be registered very quickly, yet still works exactly the same as if you had waited until the ready event.



   type="text/javascript" src="jquery.js"></script>
   type="text/javascript">
    
    $('#MyTable tr').live('click', function () {
      $(this).toggleClass('highlight');
    });
 
    
    $(document).ready(function() {
      $('#MyTable tr').live('click', function () {
        $(this).toggleClass('highlight');
      });
    });

Example: $.ajax()

Another situation where $(document).ready() may be holding you back is when you make an AJAX request immediately as a page is loading. Displaying recent Twitter updates is a common example of that:



   type="text/javascript" src="jquery.js"></script>
   type="text/javascript">
    $(document).ready(function() {
      
    });

Even though the $.getJSON() snippet is located at the beginning of the page, it isn’t executed until the entire page has loaded and the ready event has fired. Why wait until the page is loaded in order to begin the AJAX request?



   type="text/javascript" src="jquery.js"></script>
   type="text/javascript">

This is a nice improvement even when you’re making a request to a local endpoint, but is even more beneficial here because third-party requests circumvent the browser’s per-domain request limit. That third-party request to Twitter runs in parallel with the rest of the page’s normal loading timeline.

Better yet, since the dynamic script element injection used in a JSONP request is asynchronous, there’s no drawback to initiating the request early. Even if Twitter is slow or down (imagine that), the request won’t drag the page down.

Benefit: Performance

To show you a visualization of how the previous two approaches differ, I used my own site as a guinea pig. First, I wrapped a $.getJSON() request to Twitter in $(document).ready() and placed it in the of my site template.

This is how the site loads in that configuration, taken from Firebug’s Net tab:

Now, here’s the same $.getJSON() request, located in the same position in the of the page, but without the $(document).ready() wrapper:

We just pulled a bit of performance right out of thin air. This isn’t simply perceived performance, which is nice enough, but a truly faster overall load time.

Note: You might notice that the ready event came later in the second example and be concerned that it was due to the early $.getJSON() request. It wasn’t. If you look closely, a blocking

Extending jQuery to use native JSON parsing

In my previous post, I demonstrated how to use jQuery’s dataFilter to transform a JSON response before it is returned to the $.ajax() success handler. In the process, we also preempted jQuery’s default method for deserializing JSON data.

The focus at that time was implementing the same method for JSON parsing that jQuery uses by default, so eval() was still used. However, we can also use the same dataFilter mechanism to force browser-native JSON parsing instead.

Using our JSON parsing detection code and a dataFilter callback, upgrading jQuery to use browser-native parsing is simple:

$.ajax({ // Your usual $.ajax() URL, data, dataType, etc. dataFilter: function(data) { if (typeof (JSON) !== 'undefined' && typeof (JSON.parse) === 'function') return JSON.parse(data); else return eval('(' + data + ')'); } });

Because jQuery only attempts to deserialize JSON responses if their type is string, and because the dataFilter callback executes before jQuery would normally perform that deserialization, this technique preempts jQuery’s JSON evaluation completely. In the worst case, it will simply revert back to the same eval() method that jQuery internally uses by default anyway.

Note: It’s important to keep in mind that the dataFilter will run regardless of what type is actually returned from the server. You should only use this when you’re sure that you’re receiving a JSON string.

Conclusion

If you’ve been paying close attention to jQuery’s ongoing development, you may already know that jQuery 1.3.3 will provide functionality very similar to what I’ve shown you. I decided to go ahead and write this post anyway for a few reasons:

You can use this today, without waiting for jQuery 1.3.3.

You can use this in previous versions of jQuery, if upgrading isn’t feasible for you (as is often the case with plugins dependent on older versions).

If you use my technique for isolating your code from ASP.NET AJAX’s “.d”, you will still need a method for deserializing JSON in the dataFilter.

Speaking of that last point, if you’re using jQuery with ASP.NET AJAX services, be sure to watch out for the next post in this (accidental) series. There is at least one more productive step left in improving this workflow that I have been using in my projects and want to share with you soon.

You've been reading Improving jQuery’s JSON performance and security, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

Related posts:
Never worry about ASP.NET AJAX’s .d again

Using jQuery to Consume ASP.NET JSON Web Services

3 mistakes to avoid when using jQuery with ASP.NET AJAX

Never worry about ASP.NET AJAX’s .d again

Dave Ward — Mon, 29 Jun 2009 05:00:48 +0000

When I recently received this message from a frustrated reader:

After hours and hours of slamming my head into the desk it turns out it was the darn "d" in the response. My home computer is on .NET 2.0 and my work computer is on 3.5. Jimminie Christmas!

I realized that the “.d” introduced in ASP.NET AJAX 3.5’s JSON responses is still all too common a stumbling block when calling ASP.NET AJAX services through a library such as jQuery. In fact, with jQuery’s popularity among ASP.NET developers on the rise, this appears to have become an even more frequent problem.

Since a lot of people are having trouble with it, I want to share one method you can use to completely isolate your code from the problem. If you bake this into an $.ajax() code snippet or otherwise use it as a template for calling ASP.NET AJAX services in jQuery, you should never have to think or worry about the “.d” again.

In this post, I will show you how to detect the “.d” and how you can completely isolate your $.ajax success handler from it.

“.d” what?

If you aren’t familiar with the “.d” I’m referring to, it is simply a security feature that Microsoft added in ASP.NET 3.5’s version of ASP.NET AJAX. By encapsulating the JSON response within a parent object, the framework helps protect against a particularly nasty XSS vulnerability.

Before ASP.NET 3.5, “ScriptServices” and page methods returned their data at the top level of the JSON response, like this:

In ASP.NET 3.5 and later, the same server-side code returns this:

For more information about the change and why the change is a good one, be sure to see my earlier post: A breaking change between versions of ASP.NET AJAX.

However, what my previous post lacks is a solution for mitigating the inconsistency entirely. Using different client-side code against 2.0 and 3.5 based services is workable, but far from ideal. Wouldn’t it be nicer to not have to worry about it?

Determining whether or not the “.d” is there

In order to isolate ourselves from the “.d”, we first need a reliable way to test for its presence. Though JavaScript provides several methods for determining this, I suggest hasOwnProperty, as recommended by Douglas Crockford.

By using hasOwnProperty, your code is protected against unexpected changes to an object’s prototype chain. Though it is an unlikely problem to encounter, it’s always best to code defensively in JavaScript. The browser is a hostile environment!

Using hasOwnProperty to test for “.d”, you might end up with something like this:

$.ajax({ type: "POST", url: "WebService.asmx/MethodName", data: "{}", contentType: "application/json; charset=utf-8", dataType:"json", success: function(msg) { if (msg.hasOwnProperty("d")) // Leave the .d behind and pass the rest of // the JSON object forward. DoSomething(msg.d); else // No .d; no transformation necessary. DoSomething(msg); } }); function DoSomething(msg) { // Do something with the response data here. // Expect it to consistently have no .d. }

This code will perform identically against any version of ASP.NET AJAX.

Unfortunately, this might still get in your way. You may not always want to use the response in a call to another function, and you’ll have to remember the conditional every time you write a success handler.

Don’t make me think

I prefer a solution that doesn’t touch the success handler at all. Then, you’re free to integrate the “.d” handling into a generic $.ajax code snippet in Visual Studio and/or easily copy-paste it between files without modification.

Luckily, jQuery provides a mechanism that allows us to do just that: dataFilter.

The dataFilter parameter to $.ajax allows you to arbitrarily transform a response just before the success handler fires. Specifically tailored to this sort of situation, it passes response data into a callback function, captures the return value of that callback, and then passes the modified data into your success handler.

Hence, you can forever stop worrying about that pesky “.d” like this:

$.ajax({ type: "POST", url: "WebService.asmx/MethodName", data: "{}", contentType: "application/json; charset=utf-8", dataFilter: function(data) { // This boils the response string down // into a proper JavaScript Object(). var msg = eval('(' + data + ')'); // If the response has a ".d" top-level property, // return what's below that instead. if (msg.hasOwnProperty('d')) return msg.d; else return msg; }, success: function(msg) { // This will now output the same thing // across any current version of .NET. console.log(msg.foo); } });

Now, regardless which of these JSON forms the server returns:

// ASP.NET 2.0 with the ASP.NET AJAX Extensions installed. {'foo':'bar'} // ASP.NET 3.5 and 4.0. {'d':{'foo':'bar'}}

Your success handler will simply receive this consistent JSON object every time:

{'foo':'bar'}

dataType: none of your business

It’s important to note the removal of the dataType parameter in the $.ajax() code above. This is required in order to prevent a double-eval of service responses containing only a single string.

Internally, jQuery uses a combination of the dataType parameter and the implicit type the response. If the dataType is "json" and typeof(response) is “string”, then jQuery uses eval() to deserialize the response.

In the example above, manually deserializing the response in dataFilter results in it being of type Object, jQuery leaves it alone, and our dataFilter’d object makes its way back to the success callback either way.

However, if the dataType is set to “json” and the “.d” sanitized response happens to be of JavaScript type “string”, jQuery will assume that it is a JSON response from the server and still needs to be deserialized. That will throw an error at best.

The solution is to simply drop the dataType parameter from the $.ajax() call. It is only needed for purposes of instructing jQuery how to deserialize the response, and we’re handling that ourselves now.

Thanks to Brett for pointing this out.

Wait, isn’t eval() supposed to be evil?

If the eval() usage gives you pause, don’t worry. For now (as of jQuery 1.3.2), this is the same mechanism that jQuery uses to deserialize JSON too. Though eval() is potentially evil, it is still a necessary evil in many browsers.

In my next post, I’ll show you how to modify this to leverage a native browser implementation of JSON.parse instead of eval(), available in some newer browsers.

That post is available now: Improving jQuery’s JSON performance and security.

You've been reading Never worry about ASP.NET AJAX’s .d again, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

Related posts:
3 mistakes to avoid when using jQuery with ASP.NET AJAX

Using jQuery to directly call ASP.NET AJAX page methods

A breaking change between versions of ASP.NET AJAX