It was great to see all the positive responses to the screencast I recently recorded with Craig Shoemaker on how to use Firebug’s console to learn jQuery. That being my first screencast, I really appreciate all of your support.

However, you almost unanimously commented that it was too difficult to read the commands typed at the console, and you were right. So, Craig and I re-recorded the entire thing, paying extra attention to the legibility of the end result.

Craig also managed to edit the same content down to 9:59m this time, so you can watch it on YouTube if you prefer:

If the HQ version of the YouTube video still isn’t legible enough for you, Craig also made a full resolution WMV available as well.

While there’s no question that HTML, CSS, and JavaScript form the foundation of modern web development, achieving fluency hasn’t been easy for everyone. In particular, the transition from stateful development with pixel-precise layout – such as VB6 offered – has proven to be especially difficult. HTTP’s stateless nature and HTML’s relatively imprecise layout present a new, different set of challenges.

WebForms aspired to insulate us from those inconveniences. Promising rapid, drag ‘n drop layout and event-driven programming, WebForms was an attractive choice for anyone struggling with web development closer to the metal. Unfortunately, it has become apparent over the years that the WebForms abstraction, while convenient, can easily cause more problems than it solves.

More recently, Silverlight’s WYSIWYG layout and choice of familiar CLR languages have made it a similarly enticing alternative to HTML, CSS, and JavaScript among some .NET developers, but is history repeating itself? Are we leveraging Silverlight to move the platform forward or is it being used as another crutch?

Specifically, I want you to consider three areas that are negatively impacted by overzealous use of Silverlight: Usability, accessibility, and maintainability.

Click here to read the rest of this post »

Though the version number only inched up 0.0.1 with this release, it brings quite a few new features; most of them in response to your requests. I can’t include every request, but I will continue to improve the control based on your feedback, so keep them coming.

Changes in v4.1.5 include:

• Updated the base Highslide JS library to v4.1.5.
• Updated the embedded CSS to the latest version bundled with Highslide JS. This fixes the issue with the transparent/blank bar during enlargement if a caption is set.
• A few internal improvements that should make it work more reliably in some situations.

Click here to read the rest of this post »

UPDATE: We’ve recorded a higher quality version of this screencast.

When I hear that someone’s having trouble learning JavaScript or jQuery, my first suggestion to them is always the same: install Firebug and experiment at the console. Whether you’re an experienced JavaScript developer or haven’t written a single line of client-side code, the interactive nature of a command-line is one of the fastest ways to learn.

To demonstrate just how effective Firebug’s console can be, Craig Shoemaker and I recorded a short screencast on the topic. If you’re not taking advantage of this technique, be sure to take a minute (well, 16) and check it out:

http://polymorphicpodcast.com/podcast/video/firebug-and-jquery/

http://encosia.com/2009/09/21/updated-see-how-i-used-firebug-to-learn-jquery/

Question: Would you like to see more screencasts similar to this one?

If you’ve been reading long, you might remember that I’ve been a fan of ASP.NET AJAX in Action since the original was published. By avoiding heavy reliance on drag ‘n drop methodologies, the Manning book leaves readers with a deeper understanding of the framework.

Without understanding the underlying mechanisms well, developing successful solutions is as much a function of luck as it is skill; especially when it comes to debugging and maintenance. So, I think a comprehensive book like this is absolutely essential.

Click here to read the rest of this post »

As jQuery’s popularity in the .NET community has risen over the past year, one recurring theme I’ve seen is the desire to refactor away the details of using it to call ASP.NET AJAX services. Whether through helper function or specialized jQuery plugin, I’ve seen numerous methods proposed and/or in use.

Personally, the syntax never bothered me. The contentType parameter is ugly, but I have a Visual Studio code snippet for the $.ajax call and rarely think about it.

That came to an end earlier this year, when I started using dataFilter. I needed to isolate my code from the “.d” issue, and wanted to take advantage of browser-native JSON parsing in Firefox 3.5 and IE8, which required a bulky dataFilter.

Repeating that entire callback function in every $.ajax call was not acceptable. So, I was happy to learn that jQuery provides an excellent solution for consolidating settings to be used in multiple instances of $.ajax.

In this post, I’ll show you how to use that consolidation feature, and exactly how I am now using that to more simply call ASP.NET AJAX services with jQuery.

Click here to read the rest of this post »

When you’re working with JSON, performance and security are often opposing, yet equally important concerns. One of these areas of contention is handling the JSON strings returned by a server. Most JavaScript libraries do a great job of abstracting away the details, but the underlying process has long been a frustrating exercise in compromise.

On one hand, eval() is the fastest widely available method, but it is not safe.

On the other hand, textual JSON parsers written in JavaScript may be much safer, but are dramatically slower. In client-side situations, where milliseconds count, such a large performance overhead is typically too prohibitive to accept.

Recently, an exciting new alternative has emerged: browser-native JSON parsing. Integrating JSON parsing as part of the browser’s implementation of JavaScript allows for using the more secure parsing method, and even provides performance faster than eval() offers.

To take advantage of that, this post will show you how to detect whether or not a browser supports native JSON parsing, and how to force jQuery to use browser-native parsing in its $.ajax calls when it is available.

Click here to read the rest of this post »

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.

Click here to read the rest of this post »

As a longtime listener myself, I was eager when Craig asked me to come on the Polymorphic Podcast to talk about jQuery. I’ve always enjoyed how he doesn’t shy away from talking about HTML and JavaScript, which is still too uncommon in the .NET world.

With that in mind, I knew we’d be able to have a great conversation about jQuery and the concerns that ASP.NET developers run into when using it. I really enjoyed recording the show, and think it turned out pretty well. I hope you’ll enjoy it too:

Polymorphic Podcast: jQuery Secrets with Dave Ward

If you haven’t yet, I highly recommend subscribing to Craig’s podcast. There are some real gems in his previous shows too, so check those out as well.

As an ASP.NET developer working on the client-side, one problem you’ll encounter is how to reference the HTML elements that ASP.NET web controls generate. All too often, you find yourself wasting time trying to reference TextBox1, when the element is actually rendered as ctl00_panel1_wizard1_TextBox1.

Much has been written about this, including a post of my own, so I won’t go into detail about many of the workarounds. Instead, I want to take a closer look at the performance drawbacks of one popular solution: the [attribute$=value] selector.

By specifying id as the attribute in this selector, you can avoid ASP.NET’s ClientID issues completely. No matter what the framework prefixes your rendered elements with, they still “end with” the ID you specify at design time. This makes the “ends with” selector a convenient alternative to injecting a control’s ClientID property via angle-brackets.

However, are we trading performance for this convenience? If so, how much?

When Craig Shoemaker asked that question while interviewing me for an upcoming episode of Polymorphic Podcast, I realized I didn’t know the answer as clearly as I’d like. So, I decided to do a bit of benchmarking.

In this post, I’ll share the results of that benchmarking, and show you one way to significantly improve the performance of this convenient selector.

Click here to read the rest of this post »