jQuery for the ASP.NET Developer

There are dozens of separate posts here describing various approaches ASP.NET developers can use to make effective use of jQuery. Whether you want to layer a simple UI effect onto an existing WebForms application or you want to architect a completely jQuery-centric application, there’s a decent chance I’ve written about it here at one point.

Unfortunately, finding your way through all of those posts isn’t always as easy as it should be. Worse, it’s all too easy to find your way to one post that begins to cover a topic, but not realize there are several subsequent posts that would leave you with a much more complete understanding of the topic.

So, I created this page to combat that problem. It attempts to organize those posts into a more coherent narrative than a search engine can hope to provide. My intent is to continually update and improve this page over time, so please do get in touch with me with any feedback you have.

Curiosity: Augment traditional ASP.NET pages with jQuery

One of the easiest ways to augment an ASP.NET application with jQuery features is to layer them on top of the functionality that ASP.NET already provides.

Faking it: UpdatePanels

The UpdatePanel is inefficient, but it’s a tool that has enjoyed significant adoption despite its drawbacks. Though its server-centric approach to AJAX places limits on the level of interactivity you can achieve, it’s possible to layer some of jQuery’s niceties on top of an UpdatePanel by using the client-side events that ASP.NET AJAX exposes when you add a ScriptManager and UpdatePanel to your pages.

jQuery and ASP.NET can play well together

It’s a common misconception that ASP.NET is limited to generating markup too sloppy to easily use client-side libraries against. Though it’s certainly possible to use WebControls that generate embarrassingly bad HTML, ASP.NET is just as capable of outputting clean pages that are easy to extend on the client-side.

Using jQuery Validation instead of ASP.NET’s

Once you’re accustomed to using the jQuery Validation plugin on the client-side, going back to ASP.NET WebForms’ server-centric approach to validation isn’t an attractive option. Sure, ASP.NET’s validation controls do provide rudimentary client-side feedback, but that doesn’t compare to the control that jQuery Validation offers.

Unfortunately, plugging jQuery Validation into a WebForms page isn’t entirely straightforward due to WebForms’ being architected around a single form per page. Some time ago, I came up with a workaround approach for making jQuery Validation work with a WebForms page anyway.

Interest: Bridge the gap between client and server

Eventually, using jQuery to add superficial enhancements isn’t enough. Searching for a direct bridge between jQuery and ASP.NET is a natural next step for websites and applications of any significant complexity.

Let ASP.NET handle the tedium for you

One of the mistakes you’re most likely to make when you’re getting started with ScriptServices and page methods is manually intervening in the serialization process. Since it’s well-known that JSON is the preferred transfer format, it’s natural to assume that you probably need to do something in order to achieve that.

ASP.NET automatically defends your data… and breaks your code

Regardless of which approach appeals to you, there are a few techniques that will improve your development experience. First, it’s important to understand the .d that ASP.NET 3.5 introduced into all of its JSON responses. I also wrote about a few ways to normalize away the .d so that the same client-side code works against ASP.NET 2.0 and ASP.NET 3.5+, but that really isn’t a very common requirement these days. The important thing is to understand that the .d is present (and optionally to understand why it’s a useful feature).

A few troubles you may run into when sending JSON to ASP.NET

Not only do these handy communication features respond with JSON formatted data, but they also expect you to send JSON formatted data to them. That can be tricky at first, because it goes (very) slightly against jQuery’s grain. One of the most common errors you’ll encounter when sending data for the first time is the fairly nondescript “Invalid JSON Primitive” error, which occurs when you fail to send a JSON string as the AJAX request’s data parameter.

Once you’ve mastered that nuance, there probably aren’t any more “gotchas” remaining. However, building strings of JSON interspersed with your client-side data becomes very unwieldy in a hurry. A much better alternative is to use data transfer classes (also known as ViewModels) on the server-side that match up to client-side data structures and let ASP.NET handle the translation for you automatically.

Building bridges (across domains)

One of the measures that browsers take to protect users against malicious sites is restricting XMLHttpRequest to communication only with the same “origin” that the page it’s running on came from. Unfortunately, that security precaution often thwarts benign requests you might want to make to services simply running on different ports or subdomains.

There are three basic approaches to working around this problem:

JSONP – If the service you want to request across domains supports JSONP, that’s one commonly employed option. Unfortunately, the JSONP approach isn’t capable of anything beyond a simple GET with querystring parameters. Obviously, that’s not suitable for use with the services described above since they require a POST request.

I’ve used your posts a lot, and find them to be very helpful. One problem I always run into is that I end up being stymied by the fact that webmethod routines have so little access to the real guts of the page because they have to be static. Maybe I’m missing something, but I am quickly coming to the conclusion that webforms and using javascript for anything truly powerful just doesn’t work. Am I missing something?

When I began writing these posts, I was using WebForms and found ways to make it work (because I had to; there was no MVC at that time). The key is to abandon the server-centric mindset and avoid trying to do something like access the Page’s controls from within a page method.

Instead, take a client-centric approach. For example, gather the values you need on the client-side and send them along with the request. Similarly, you can set the value of those controls on the client-side when the response comes in. It turns out not to be much more work than the old WebForms, server-centric approach, but the performance boost is huge and you get a great deal more control over the client-side UX.

I wanted to thank you for all these posts on integrating ASP.NET with jQuery, they’ve helped me improve the projects I’ve worked on a lot.

I’m a relatively new developer (less than a full year of experience), who started out with ASP.NET web forms. Between using the tips and tricks listed here and a bit of knockoutjs, I feel like I’ve really made some great improvements over what I had been using (UpdatePanels with full page postbacks).

However, I feel like now that I’ve gone down this route, I’m missing the point, so to speak, of ASP.NET web forms. My code behind for my current project looks like a Page_Load and a bunch of Web Method functions called via jQuery Ajax. I’m wondering if I should be looking into moving over to MVC. I’ve already walked through a tutorial and it seems like a great framework with much better interaction between ASP.NET and Javascript. I’d like to learn MVC, and have a basic understanding the underlying design concepts from using knockoutjs. But I’m still far from being a pro at ASP.NET web forms yet, so I’m concerned I’m ‘abandoning’ it too early without fully understanding it.

I know there’s no simple answer to “which framework should I be using?” but I wanted to get your thoughts on this.

Personally, I haven’t been using WebForms for new projects since about the time MVC 2 shipped. A lot of my posts about using jQuery with WebForms came before MVC was released, so they were more about making WebForms an environment I could enjoy than they were about promoting WebForms as the best solution. If you’re comfortable with the closer-to-the-metal approach that my AJAX/jQuery posts and most MVC work entails, MVC is probably the better framework for you.

Are you still keeping this page of links up to date? Is it still relevant? I’m a late-comer wanting to rip out all my ASP.NET AJAX code and switch to pure jQuery / JavaScript AJAX callbacks. This looks like a great resource to start.

I haven’t been updating it very much lately, because I haven’t written many posts that fit on this list.

I would say that switching to a client-side approach is better today than it ever has been. I still use jQuery (and other libraries) with ASP.NET regularly. I would say that Web API is a much better choice for the backend now than the ScriptService/WebMethod approach from back when I began writing about them (Web API wasn’t available back then).

Finally, it does still make good sense to stick with server-side rendering for content where SEO is important. There are SEO workarounds for client-side rendering, but it’s unnecessary complexity. I like to make a distinction between document based sites (like a blog) and sites that act more like an application. In the former, server-side rendering still has its place, but moving farther to the client-side is great for sites that function more as applications than websites.

Yes, Web API looks like the way to go. We’ll get there eventually! I’m working on a very large and very business critical internal web forms app. One of those that constantly lags behind but needs dragging into the present slowly and carefully! So SEO is not an issue.

We’re still on .NET 3.5 so I don’t think Web.API is available to us yet – but I think that will be the target – and probably a slow migration to MVC. First we need to loose all the old UpdatePanels and heavy ASP.NET AJAX stuff – yes, we still have them in there!

I am new to jQuery and your blog has been a valuable resource! Thanks!!

We have several Asp.net web forms applications. We would like to move to jQuery slowly and as a first step, want to replace asp.net grid with a jqgrid. But have a lot of code in the server side for binding data to asp.net grid control. Is it even sensible to consider this approach as jQuery is asynchronous but the asp.net page has a Submit button and a lot of server side code in the code-behind? Please advice.

I’m trying to find basic, hello world type of guidance on how to place a databound formview on a modal jquery dialog, in a web form. Any ideas how this can be done? I haven’t had any luck yet. Thank you

That should be easier than it might sound. If you put the FormView in a modal dialog’s container div, the server will render that on page load and it can lay there in wait to be displayed in the dialog on the client-side. Have you tried anything like that and run into trouble?

Leave a Reply

Use <pre lang="x">code</pre> to include code blocks with syntax highlighting, where x is asp, csharp, html, javascript.
Even inside <pre> and <code> blocks, the open angle brackets in HTML and XML need to be encoded (i.e. convert any
< to &lt;).

Notify me of followup comments via e-mail. You can also subscribe without commenting.