Microsoft's AJAX Toolkit vs. jQuery

Question

Our team has been using Microsoft's AJAX Toolkit since the days of Atlas. In a bit of naivety we missed the jQuery/Prototype phenomenon until a month or two back. Until now, we have always associated the concept of Ajax with Microsoft's toolkit.

In reading up on jQuery I'm seeing a whole new side of Ajax that I was only vaguely aware of. That is, you can use JavaScript (or a JS library) to talk to the server without using a specialized control. At first glance, it seems like this offers better browser compatibility and less bloat. I'm certainly interested in it.

My question to the community:
When working with ASP.NET and faced with the need to communicate with the server without a postback, how does one make the determination to use a control from the AJAX Toolkit instead of working with something like jQuery? Is there a reason to use both?

Answer 1

imo it is down to which ever you prefer.

Microsoft uses drag & drop controls like update panel, where as jquery is written by hand and in my experience offers a greater degree of flexibility.

JQuery seems to be the framework of choice at the moment for DOM scripting and AJAX, it just makes javascript related tasks a lot quicker and easier to implement.

Answer 2

Good question.

I believe that while there's still place for the AJAX Toolkit controls--as there is for classic Web Forms--your code will be cleaner and easier to maintain when using jQuery. But above all you'll have much more control and flexibility over how your code behaves.

You can always use some controls for specific situations, using jQuery for the rest. I don't think there is anything fundamentally wrong with employing both approaches simultaneously.

Answer 3

I've found the proficiency of the team with JavaScript and the DOM makes a huge difference on the uptake of jQuery over MS controls. If the team is happily unaware of the DOM, HTTP, asynchronous operations, event driven UIs, or what JSON means and why it's the cat's meow, I'd stick with AjaxControlToolkit.

If on the other hand they are consistently trying to work around the toolkit to manipulate a control directly via JavaScript, jQuery takes the pain out of manipulating the DOM like this.

In the end, if your team can get to market faster with .NET controls, stick with it for the overall delivery of the app and have them slowly try jQuery for bits and pieces here and there (animations, jquery ui, .bind() and separating behavior from presentation). Eventually you either a) get enough experience that you can transition new pages/apps to 100% jQuery or b) make enough money to hire someone proficient at DOM scripting and teach the team themselves ;)

Answer 4

While the Microsoft AJAX Toolkit is convenient and simple to drop in, its easy to quickly hit barriers when you want to do anything more complicated than what you designed. If you're interested in learning the ins and outs of AJAX with a friendly library, JQuery is the way to go. This knowledge will translate across multiple platforms; for instance, if your team decides to try using Django, Ruby on Rails, etc. then you already have JQuery as your go-to AJAX toolkit. This is especially true if you're ever planning to move from ASP.NET to ASP.NET MVC for which Microsoft has dubbed JQuery the official client-side javascript toolkit.

Answer 5

I stopped using the MS Ajax stuff a long time ago because many of the applications I develop need to be accessible and degrade gracefully. i.e. Unobtrusive Javascript. I firmly believe that MS will eventually move their Javascript stuff in that direction but not just yet.

Basically every web page I develop will have no inline javascript whatsoever bar the external links to js files and the page will work with javascript off. This is my priority but may not be yours or anyone elses. These days we wouldn't dream of placing a font tag in html rather than our external css files. Over time we will probably think the same about script.

Answer 6

AJAX Toolkit is a product of a great "legacy problem" issue. MSFT has to support ASP(X), web forms, etc... ASP (and JSP) are implementations of 10+ years old concept: creating HTML page on the server side. The whole "interactivity" is/was achieved with FORM submit. And inevitable page re-loads. Page design was/is possible only with Visual Studio, and in reality is very difficult. All together this is not AJAX. World has moved on. jQuery means AJAX. jQuery is javascript library for AJAX clients. It uses DOM and few other HTML+browser features. AJAX/jQuery is server agnostic: any web server will do. AJAX and jQuery, means total decoupling. MSFT AjaxToolit is very closely coupled with ASP(X), and inevitably IIS. That was yesterday. On the other side, jQuery is forcing you to adopt thinking of today. Which is a good thing, especially if you are raised on ASP, and you want/need to move on.

Fortunately MSFT has realised it has to move on too, and ASP.NET MVC + jQuery was "allowed". It is not 100% AJAX architecture, but a very good step into the right direction. It is not webforms. It is not ascx.

Advice: never have one team develop web server side and web app client side. Use AJAX+REST+JSON. Have two decoupled teams developing loosely coupled web app.

--DBJ

Answer 7

Ah, and the crucial difference is:

AJAX.NET is built on JScript + simulated Class approach.

jQuery is built on JavaScript : an pure PROTOTYPE approach.

--DBJ