I recently received this email from an MSJoe blog reader.

Hi Joe, thanks for the posts about jquery..


I’m now wondering, we are using the ms ajax toolkit. I like the simple use of it. Now doing jquery you will have to write javascript, which will have the advantage that all cpu cycles are spend on the client side for rendering the validation controls (the toolkit does something on serverside first)


Do you see any advantage of doing the jquery way instead of the ajax toolkit? Or is it just releasing yourself from a dependency on the toolkit and the minimal extra rendering effort for the server with the toolkit?



With the senders permission, I thought it would be interesting to answer here, it’s a great question and one that I’ve received many times. .

To be clear, Microsoft continues to support the Ajax Control Toolkit. Support though, means bug fixes.

If the Ajax Control Toolkit works for you, you certainly can continue to use it. I certainly wouldn’t spend a bunch of time retrofitting pages that use the Ajax Control Toolkit if just to switch to jQuery.

But, in my opinion,  for new development there are a number of advantages to using jQuery.

Not the least of which is that the Ajax Control Toolkit is “frozen”. Not only will there be no new controls / extenders, but there are no feature enhancements planned for any of the controls. Most of the controls are “version one" at best. There will not be a version 2 (or even a version 1.1).

Even thought the ACT (Ajax Control Toolkit) is “Open Source”, folks have adopted it as a “Microsoft Product” and it hasn’t really enjoyed much up-take by community contributors.

Since it’s open source, you could modify or extend it yourself, but it’s a pretty big time investment to come up to speed.

jQuery, jQuery UI, and the plethora of jQuery Plug-Ins offer a great alternative, but not a seamless one.

While jQuery is new, frequently updated, rich and elegant, and has a vibrant active community who contributes new plugins every day, for the Classic ASP.NET Developer, there is a big perspective change to tackle.

jQuery is JavaScript. There is no server-side technology involved.

Many  “WebForms”  developers are new to JavaScript, CSS, and the DOM.

When you use jQuery for your ASP.NET User Interface, there are no “server-side” events for you to code against and no “server-side” properties either (like the user entered value of a text box).

In a WebForms application, basically all control events cause a form post-back.

Using jQuery (CSS and HTML) the UI elements run entirely on the CLIENT. When you need to execute code on the server (C#, VB.NET etc.) you have two options.

  1. Submit the complete form back o the server.
  2. Connect a JavaScript function to an event handler for the user interface element and make a JavaScript Ajax call back to a service method on the server.

That’s a pretty different model that the one WebForms developers are used to.

Apart from the above, what are the advantages of moving to this web application development model?

Well, I think there are several.

  1. The browser doesn’t have to be dumb. Browsers can run CODE, but when we don’t implement anything in JavaScript we haven’t federated any logic. Even though we have a powerful processor on the user’s computer where the browser is running, we’re not using any of that computer’s processing power. That means we’re consuming more resources on the server than we need to. This has a negative impact on your performance and scalability.
  2. A UI that responds to user input and executes logic, updates the user interface and interacts with the server without the user needing to wait for a page post back makes for a better User Experience.
  3. This type of experience is increasingly expected by web application users.
  4. JavaScript has become ubiquitous. Your JavaScript skills can be useful on the client, server and desktop.
  5. Everything is Open Source JavaScript so you can modify to your heart’s content.

Does that make sense ?