views:

241

answers:

5

With .NET 4.0 on the horizon will MS AJAX still have a place or do you think JQuery will expand to to include the full functionality of AJAX and make, MS AJAX as we know it redundant?

A: 

Im sure MS will still support Asp.Net Ajax (I pray they do some major improvements), but I think the inclusion of JQuery in Visual Studio is a strong sign of something, I just dont know what. Maybe somebody that went to PDC '08 could give us a direction of where MS is taking Asp.Net Ajax.

Mike_G
A: 

jQuery is all about the DOM. So in that regard I imagine all of the DOM related code in MicrosoftAjax.js will change to simply point to the jQuery equivalents. For example:

Sys.UI.DomEvent.addHandler = function(element, eventName, handler) {
    jQuery(element).bind(eventName, handler)
}

Sys.UI.DomElement.getLocation = function(element) {
    var jPos = jQuery(element).offset();
    return new Sys.UI.Point(jPos.left, jPot.top)
}

However everything else "framework" related will probably stay: Sys.Component, Sys.Net.WebServiceProxy, Date.format(), Enums, Type.registerClass() (and class inheritance in general), Function.createDelegate(), pageLoad(), and the list goes on and on.

Crescent Fresh
+1  A: 

From Scott Guthrie's Blog:

Going forward we'll use jQuery as one of the libraries used to implement higher-level controls in the ASP.NET AJAX Control Toolkit, as well as to implement new Ajax server-side helper methods for ASP.NET MVC. New features we add to ASP.NET AJAX (like the new client template support) will be designed to integrate nicely with jQuery as well.

So, it seems to me that MS AJAX will start consuming and using JQuery when rendering javascript on the client.

NerdFury
+1  A: 

Based on what I've heard to this point, nothing in the ASP.NET AJAX libraries will be replaced by jQuery. Microsoft will just be adding the jQuery libraries to the distribution. Basically, you'll have the same options as you do today without the additional download of the jQuery libraries.

In terms of the future of ASP.NET and ASP.NET AJAX, there have been some announcements. Check out the following Channel 9 videos:

10-4 Episode 8: Pure Client-Side Development with ASP.NET AJAX 4.0

Stephen Walther - New Features of ASP.NET 4.0

In terms of uses of the technologies, I think people will stick with ASP.NET AJAX when making client-side service calls. It's so much easier. I think people will also adopt the client-side templates. There's some pretty cool stuff in there. Many of the rest of the client-side programming (e.g. event handling and DOM manipulation) will be done with jQuery.

Rob Windsor
+2  A: 

Keep in mind that ASP.NET AJAX is comprised of both the client-side JavaScript library (MicrosoftAjax.js) and the server-side components in System.Web.Extensions. jQuery's inclusion probably won't affect the server-side portion of ASP.NET AJAX at all.

On the client side, jQuery can do literally everything that MicrosoftAjax.js can today. MS AJAX makes calling ASMX/WCF web services a little easier (at the cost of heavier footprint on the client-side), but jQuery can call ASP.NET AJAX services just as well.

Based on what we've been seeing on the CodePlex previews so far, Microsoft appears to be focusing on client-side templating, client-server integration with ADO.NET Data Services, two way "live bindings" for data in client-side templates, and other things similar to those. Basically, focusing on the .NET specific client-side issues that jQuery doesn't address.

So, to answer your question, I think that jQuery usage will likely expand into most of the areas that ASP.NET AJAX's client-side library currently occupies, but ASP.NET AJAX's client-side library will evolve to become other useful things that jQuery doesn't provide.

Dave Ward
"jQuery can do literally everything that MicrosoftAjax.js can today" is categorically untrue. It is only true for DOM related functionality of MicrosoftAjax.js.
Crescent Fresh
I use jQuery exclusively when consuming ASP.NET AJAX web services and page methods. That's certainly not a DOM related function.
Dave Ward
Dave, Can you take a look @ this post - Put this up after reading 'Easy Refresh update panel with JS' on Encosia - http://stackoverflow.com/questions/642060/using-dopostbackupdatepanel-from-a-userctrl-in-a-webpartzoneThanks.
JamesM
@Dave: XMLHttpRequest is part of the DOM api. http://en.wikipedia.org/wiki/XMLHttpRequest
Crescent Fresh
By the same token, I could say everything in MicrosoftAjax.js is DOM related since it's part of the DOM once loaded.
Dave Ward
You could say that, but you'd be wrong. For example, MSAjax.js introduces language addons (Function.createDelegate, Date.format), class inheritance (Type.registerClass), object life cycle events (Sys.EventHandlerList), Enums, etc. None of these touch, augment, nor intersect the DOM at all.
Crescent Fresh
The MSAjax "addons" are in the same scope as XmlHttpRequest. Use a decent tool to inspect the DOM and it's right there. You can't really have that one both ways.
Dave Ward
My good lord. I just realized why we're going in circles. You have no idea where JavaScript ends and the DOM begins. They are not one in the same, no matter what "tool" you use to inspect the `window` object. http://www.amazon.ca/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742 is a good read.
Crescent Fresh
Your good lord aside, I still obviously don't agree with your assessment. If you'd like to email me and discuss it properly, feel free. I'm not going to keep arguing with you and continue to pointlessly clutter up this answer.
Dave Ward