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 »

I spent some quality time with Dave Reed’s latest revision of John Resig’s jQuery.tmpl plugin recently, migrating a small project from jTemplates. Since both the jQuery team and Microsoft team have requested feedback on jQuery.tmpl, I decided to write about my experience using it (as I am wont to do with these templating proposals).

Overall, jQuery.tmpl is a great step in the right direction. It’s small, it’s simple, and it’s fast. Overloading append() to allow the append(Template, Data) syntax is phenomenal. That approach feels more like idiomatic jQuery than anything else I’ve used, including jTemplates.

However, if this template rendering engine is going to succeed broadly, I feel there’s one important feature still missing. Additionally, there are a couple ancillary features that are present in the current proposal, but should be protected.

Click here to read the rest of this post »

An overwhelming majority of people who end up on my site only view a single page per visit. In fact, you’ll probably do the same. As I’ve come to realize: that’s okay.

I didn’t always think it was okay though. Throughout most of 2007, that caused me a great deal of concern. I’d been reading too many blogs about blogging, was convinced that persuading you to click through multiple pages was essential to the site’s success, but wasn’t able to make that happen here

Ultimately, the number of pageviews wasn’t very worrisome, because the site continued to grow. What did frustrate me was the impact that single-view visits have on a more important metric.

Click here to read the rest of this post »