Pros and cons of MS Ajax vs. jQuery in an ASP.NET MVC app?

Question

Now that RC1 is out I need to decide once and for all whether to use MS Ajax libraries or just jQuery for AJAX requests. The application is a new application. Essentially the way I'll decide is whether or not i get any significant benefit from the Microsoft libraries that I wouldn't get from jQuery. I already HAVE jQuery loading and I am concerned about the extra overhead of file size more than anything.

As far as I'm aware -- the only benefit really is that there are helpers like Ajax.BeginForm, but perhaps these will work with jQuery at some point anyway? I was also told today by a government employee friend of mine that MS Ajax library has a LOT of bugs in it - which concerns me.

With Microsoft now having officially befriended jQuery I wouldn't be too worried about them doing anything in future to leave jQuery in the dust by enhancing their own libraries.

I really don't know a whole lot about exactly what MS Ajax actually does for me. Are there certain pros and cons. Or is it just 90% bloat to support 'update panel' ?

I also find it very interesting that the ASP.NET MVC in Action book just skips over the MS Ajax libraries and jumps straight into jQuery :

In this chapter the reader will examine how the ajax technique is applied to ASP.NET MVC in a more seamless way than with Web Forms. The reader will see how to leverage an increasingly popular, lightweight javascript library called jQuery.

(from free sample chapter on AJAX)

Would very much appreciate hearing from anyone about their experiences workin with both, expecially on the following additional questions :

• is it easy to convert code between the two libraries - assuming relatively simple ajax requirements ?
• is debugging notably better or faster in either library
• anybody know how ASP.NET 4.0 is progressing and any announced plans for the AJAX library that might be beneficial to MVC?
• what in a nutshell could MS AJAX do for an MVC app beyond sending requests and sticking the response in a DIV?
• how do i do the equivalent of Ajax.BeginForm(...) and use jQuery ?
• what was your deal killer one way or the other?
• what are most people out there using?

Answer 1

Personally, I would stick with JQuery. MS AJAX is pretty heavyweight in terms of size and you can do so much with JQuery. As far as whether it is easy to convert code, well it depends on how much of the MS AJAX stuff you are using. I don't think there is really much appreciable difference in debugging from one to the other. You will have a larger community of JQuery users from which to pull resources.

Answer 2

You can (and I do) use both depending on the need. When I want a particular form to be non-javascript friendly AND I'm generating content on the server, I'll use MS AJAX via the AjaxHelper. It builds everything I need on the client side to handle the non-javascript enabled browser. I only need to detect AJAX/non-AJAX in the controller and return a partial or a full view depending. If I need to use AJAX as part of a plugin (say autocomplete), then I'll use jQuery. The point is I use the tool that best suited (easiest to implement) for me. Granted, most of my apps run on an intranet so I'm much less concerned about the size of the downloads.

Answer 3

I also found the jQuery announcement about MS incorporating the library

Apparently :

Additionally Microsoft will be developing additional controls, or widgets, to run on top of jQuery that will be easily deployable within your .NET applications. jQuery helpers will also be included in the server-side portion of .NET development (in addition to the existing helpers) providing complementary functions to existing ASP.NET AJAX capabilities.

So I'm thinking its quite probable that they'll end up having jQuery helpers that exactly mirror the AJAX helpers for the MS stuff.

I guess solution I'll take is to use Html.BeginForm, and then intercept the submit button to use jQuery. I'm not especially worried about people without javascript losing functionality, but its not that much harder to do so I may as well.