I’ve noticed several people looking for a jQuery 1.5 VSDoc this week. After looking around myself, I didn’t see one anywhere either. So, I updated Damian Edwards’ VsDocBuilder for jQuery 1.5 and generated a new VSDoc.

It doesn’t handle the new jqXHR and Deferred return types quite right, so you won’t get Intellisense for the new chained $.ajax() callbacks. However, it should be better than nothing until a fully functioning version is released.

You can download it here: jQuery-1.5.0-vsdoc.js

Update: Damian has just made a fully functional version of the 1.5 VSDoc available (that was quick): jquery-1.5-vsdoc.js. You should use his instead of mine.

Important: This new VSDoc makes use of <para> tags to display line breaks inside documentation tooltips. To view them properly, you’ll need to be sure that you have the JScript Editor Extensions installed so that Visual Studio understands those new VSDoc tags.

jQuery 1.5′s complete overhaul of the AJAX API has led to several people contacting me recently, understandably nervous about how the rewrite will impact working with ASMX ScriptServices and ASPX page methods. Seeing the default calling syntax change to $.ajax(url, settings) was especially unsettling to many.

I’m happy to report that the short answer is: jQuery 1.5′s new AJAX module has almost no negative impact on any of the techniques you may have read about here. The rewrite maintains very good compatibility for the $.ajax(settings) calling syntax and for now-deprecated features such as dataFilters.

One advanced dataFilter usage appears to be broken, but it’s something that you probably already stopped using with jQuery 1.4. To be clear, I’ll briefly enumerate all of the techniques I’ve re-tested and jQuery 1.5′s impact (or lack thereof) on each.

Click here to read the rest of this post »

It’s no secret that I’m a proponent of using a shared CDN to host jQuery. As more and more sites take advantage of public CDNs for their jQuery reference, the cross-site caching benefit is becoming almost a given. However, there are a couple ways that even I recommend against using these public CDNs.

With the impending policy change on hotlinking copies of jQuery hosted on jQuery.com, I expect that at least several sites will be migrating their hotlinked script references to one of the public CDNs soon. So, I think this is a good time to address one CDN-related usage mistake that I’ve seen an uptick in lately.

Click here to read the rest of this post »

In my last post about jQuery Templates, I showed you how to use template composition to build a template out of simple sub-templates. These composite templates are a great way to address the complexity that creeps into real-world UIs, as they inevitably grow and become more intricate. However, one feature missing from my last example was the ability to store those composite templates in external files and load them asynchronously for rendering.

I’ve described how to accomplish that with single templates in the past, using jQuery’s AJAX utilities and a particular usage of tmpl(). Unfortunately, remotely loading a group of composite templates from a single file is not quite as simple, and the technique I’ve described previously will not work.

Not to worry though, it’s still relatively easy.

In this post, I’ll show you how to move a group of composite templates to an external file, how to load and render them with jQuery Templates, and how to take advantage of an expected benefit to improve separation of concerns.

Click here to read the rest of this post »

I doubt anyone was happier than I was to see that support for composite template rendering was added to jQuery Templates during the interim between the first community proposal and its recent release. If you’re a regular reader, you might remember that I personally lobbied for that functionality back in May, based on how I’ve used jTemplates’ similar #include feature.

Since then, a common question I’ve received amounts to: “Great, but why?”

I think that’s natural, because template composition is one of those things that can seem obscure until you put it to work for the first time. From that point onward, you’ll begin to see the structure of your client-side templates in a different light. Simplifying your templates into smaller logical parts and then combining those parts to create the desired end result is a powerful approach. It’s terrific for making large templates more approachable and maintainable over the lifetime of an application.

In this post, I want to show you an example of a scenario that template composition is well suited to, a couple ways that jQuery Templates’ {{tmpl}} feature can be used to simplify that scenario, and a bonus advantage that the composition approach provides even after the template has been rendered.

Click here to read the rest of this post »

Now that jQuery Templates is official and definitely will not include remote template loading, I wanted to publish a quick guide on implementing that yourself. As I mentioned previously, there’s a handy interaction between jQuery Templates’ API and jQuery’s AJAX methods that makes this easier than you might expect.

In this post, I’ll show you how to use a plain string as a template, how to asynchronously load an external template file as a string, and how to render it with jQuery Templates once it’s loaded.

Click here to read the rest of this post »

It hasn’t been easy keeping up with the twists and turns that Microsoft’s client-side frameworks and libraries have taken in the past couple years. Even today, I still hear from a surprising number of developers that don’t realize the ASP.NET Ajax Library is dead.

With that in mind, I’ve been writing an article on and off for the past several months that attempts to disambiguate Microsoft’s various client-side initiatives and hopefully provide some clarity. When Karsten from Mix Online contacted me about writing another article for them, we decided that this would be a perfect follow up to the jQuery article I wrote for them last year.

Here’s the first few paragraphs:

When Microsoft announced they would begin providing official support for jQuery, few of us realized how profoundly that announcement would eventually impact client-side development on the ASP.NET platform. Since that announcement, using jQuery with ASP.NET has moved from the obscure, to a central role in ASP.NET MVC’s client-side story, and now to the point of potentially superseding ASP.NET AJAX itself.

The journey hasn’t been all smooth. With Microsoft’s move toward jQuery, the ASP.NET AJAX, Microsoft Ajax Library, ASP.NET Ajax Library and Ajax Control Toolkit roadmaps have been uncertain at times. This has made it difficult to keep track of which projects are still relevant, and especially which you should choose going forward.

In my last article for Mix Online, I discussed what ASP.NET needed to know about jQuery from development perspective. In this article, I want to provide clarity on the events that led us to this point, talk about what portions of the current AJAX framework are and aren’t affected by recent changes and show you where we’re headed next. In addition, I’ll dive into the implications of the recent announcement about the adoption of Microsoft’s template library by the jQuery core.

Click here to read the rest of this article at Mix Online

It’s been nearly two years since I wrote about using Google’s CDN to host jQuery on your public-facing sites. In that post, I recommended it due to three primary benefits that public CDNs offer: decreased latency, increased parallelism, and improved caching.

Though the post has been overwhelmingly well-received, concerns have been raised as to whether or not the likelihood of better caching is truly very significant. Since the efficacy of that benefit depends entirely on how many other sites are using the same CDN, it takes quite a bit of research to make an objective case either way.

I’ve never been happy about responding with vague answers. Caching probability is a valid concern and deserves to be taken seriously. So, I decided to cobble together an HTTP crawler, analyze 200,000 of the most popular sites on the Internet, and determine how many of those are referencing jQuery on Google’s public CDN.

Click here to read the rest of this post »

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/

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.

Click here to read the rest of this post »