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 Friday, the “final” two episodes of Mastering jQuery went live: Using Custom Events and Upgrading to jQuery 1.4. While we’ll almost certainly add another episode when jQuery 1.5 is released, we’ve covered what we set out to.

Weighing in at nearly six hours of video, we covered a wide range of content, and have had overwhelmingly positive feedback on the series. I hope you’ve enjoyed the episodes as much as we’ve enjoyed recording them.

I want to thank those of you who helped promote Mastering jQuery through Twitter, word of mouth, and other avenues. It became one of the most viewed series on TekPub, and that couldn’t have happened without your help and support.

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 »

For several years now, I have been consistently impressed with how Microsoft’s developer division gathers feedback and proactively responds. Nearly every time that I’ve participated in a survey or otherwise provided feedback (solicited or not), someone has followed up with me about my specific concerns. In my experience with how other large companies gather feedback, that’s not common.

So, when I answered a recent survey about ASP.NET development in Visual Studio 2010, I wasn’t surprised when I received a follow-up email from a friendly fellow at Microsoft named Xinyang. In the optional comments section, I had mentioned my concern that CSS and JavaScript editing are becoming second class citizens in Visual Studio. In response, Xinyang asked me to provide more detail on that comment.

As I composed a lengthy email reply to him, it occurred to me that a post here would be a much more effective way to refine my feedback and potentially gather more responses from you at the same time.

So, here are a few of my ideas for improving client-side development in Visual Studio 2010, separated into CSS and JavaScript specific feedback. Xinyang and some of his colleagues will be reading this and your comments, so if you agree, disagree, or have other ideas yourself, be sure to chime in.

Click here to read the rest of this post »

I recently encountered what appeared to be a cross-browser issue with jQuery, which was both surprising and frustrating. After all, eliminating those cross-browser inconsistencies is no small part of jQuery’s fundamental appeal.

After some investigation, the source of the trouble actually stemmed from an oversight on my part. I doubt that many of you will have to deal with exactly the same situation, but the lessons I learned may apply to cross-browser jQuery problems you encounter in the future.

Click here to read the rest of this post »

Developing iPhone-optimized portions of an ASP.NET website presents a challenge. More specifically, it’s testing your creations that can be difficult.

Apple’s iPhone emulator only runs on Macs and the Windows-based alternatives don’t emulate mobile Safari well. That leaves us using an actual device as the only high-fidelity option for testing. That’s not all bad; especially when it comes to a touch-driven interface, testing with the real thing is preferable.

Unfortunately, the ASP.NET Development Server bundled with Visual Studio is severely restricted when it comes to testing externally. In fact, it could hardly be more restrictive – it refuses all external connections, even if those connections originate from the same local subnet.

In this post, I’m going to show you one way I’ve found to circumvent that restriction, how to configure your iPhone to take advantage of that, and how to connect to the development server once those steps are completed.

Note: This post specifically describes configuring an iPhone, but the same approach will work for any mobile device that supports using an HTTP proxy.

Click here to read the rest of this post »

One group of searches that consistently brings traffic here is variations on the error: Invalid JSON primitive. Unfortunately, the post that Google sends that traffic to doesn’t address the issue until somewhere within its 150+ comments.

Today, the topic gets its own post.

If you’ve worked with ASMX ScriptServices or Page Methods without ASP.NET AJAX’s client-side proxy (e.g. using jQuery or pure XMLHttpRequest code), you’ve may have seen this cryptic error yourself. Or, perhaps you’ve just arrived here due to seeing it for the first time.

Either way, you may be surprised to learn that the most common reason for this error is that you’ve lied to ASP.NET during your AJAX request.

Click here to read the rest of this post »

If you follow me on Twitter, this stack of free TekPub trials may look familiar:

Each card is redeemable for a one-month membership at TekPub, which allows free, unrestricted access to all of the videos on the site. Of course, that also includes access to my TekPub series, Mastering jQuery.

I’ve given many of them away at events like MIX10 and ReMIX Atlanta 2010, but made sure to reserve some of them for you. After all, there would be no Mastering jQuery series without you.

Click here to read the rest of this post »