asp.net - v15 - Kit de herramientas AJAX de Microsoft vs. jQuery

install ajax control toolkit from nuget

Question

Nuestro equipo ha estado utilizando el kit de herramientas AJAX de Microsoft desde los días de Atlas. En un poco de ingenuidad, nos perdimos el fenómeno jQuery / Prototype hasta un mes o dos atrás. Hasta ahora, siempre hemos asociado el concepto de Ajax con el kit de herramientas de Microsoft.

Al leer sobre jQuery, estoy viendo un lado completamente nuevo del Ajax del cual solo estaba vagamente consciente. Es decir, puede usar JavaScript (o una biblioteca JS) para comunicarse con el servidor sin usar un control especializado. A primera vista, parece que esto ofrece una mejor compatibilidad con el navegador y menos volumen. Ciertamente estoy interesado en ello.

Mi pregunta a la comunidad:
Cuando se trabaja con ASP.NET y se enfrenta a la necesidad de comunicarse con el servidor sin una devolución de datos, ¿cómo se toma la determinación de usar un control del kit de herramientas AJAX en lugar de trabajar con algo como jQuery? ¿Hay alguna razón para usar ambos?

Answer 1

AJAX Toolkit es un producto de un gran problema de "problema heredado". MSFT tiene que admitir ASP (X), formularios web, etc ... ASP (y JSP) son implementaciones de un concepto de más de 10 años: crear una página HTML en el lado del servidor. Toda la "interactividad" se logró con FORM submit. E inevitables recargas de páginas. El diseño de páginas fue / es posible solo con Visual Studio, y en realidad es muy difícil. Todos juntos esto no es AJAX. El mundo ha avanzado. jQuery significa AJAX. jQuery es una biblioteca de javascript para clientes AJAX. Utiliza DOM y algunas otras funciones de navegador HTML +. AJAX / jQuery es independiente del servidor: cualquier servidor web funcionará. AJAX y jQuery, significa desacoplamiento total. MSFT AjaxToolit está muy estrechamente relacionado con ASP (X), e inevitablemente IIS. Eso fue ayer. Por otro lado, jQuery te obliga a adoptar el pensamiento de hoy. Lo que es bueno, especialmente si se eleva en ASP y desea o necesita seguir adelante.

Afortunadamente, MSFT se ha dado cuenta de que también tiene que seguir adelante y ASP.NET MVC + jQuery estaba "permitido". No es una arquitectura 100% AJAX, sino un muy buen paso en la dirección correcta. No se trata de formularios web. No es ascx.

Consejo: nunca haga que un equipo desarrolle el lado del servidor web y el lado del cliente de la aplicación web. Utilice AJAX + REST + JSON. Haga que dos equipos desacoplados desarrollen una aplicación web poco acoplada.

--DBJ

Answer 2

Buena pregunta.

Creo que si bien todavía hay lugar para los controles del kit de herramientas AJAX, como para los formularios web clásicos, su código será más limpio y fácil de mantener cuando se usa jQuery. Pero, sobre todo, tendrá mucho más control y flexibilidad sobre cómo se comporta su código.

Siempre puedes usar algunos controles para situaciones específicas, usando jQuery para el resto. No creo que haya nada fundamentalmente incorrecto en el uso simultáneo de ambos enfoques.

Answer 3

Dejé de usar MS Ajax hace mucho tiempo porque muchas de las aplicaciones que desarrollo deben ser accesibles y degradarse con gracia. Es decir, JavaScript no intrusivo. Creo firmemente que MS eventualmente moverá sus cosas de Javascript en esa dirección, pero no todavía.

Básicamente, cada página web que desarrollo no tendrá ningún javascript en línea, excepto los enlaces externos a los archivos js y la página funcionará con javascript desactivado. Esta es mi prioridad, pero puede que no sea tuya o de nadie más. En estos días no soñamos con colocar una etiqueta de fuente en html en lugar de nuestros archivos css externos. Con el tiempo probablemente pensaremos lo mismo sobre el script.

Answer 4

He encontrado la capacidad del equipo con JavaScript y el DOM hace una gran diferencia en la aceptación de jQuery sobre los controles de MS. Si el equipo no está al tanto del DOM, HTTP, las operaciones asíncronas, las UI impulsadas por eventos o lo que significa JSON y por qué es el maullido del gato, me quedo con AjaxControlToolkit.

Si, por otro lado, intentan constantemente trabajar con el kit de herramientas para manipular un control directamente a través de JavaScript, jQuery se encarga de manipular el DOM de esta manera.

Al final, si su equipo puede llegar al mercado más rápido con los controles .NET, manténgalo para la entrega general de la aplicación y .bind() prueben jQuery por partes y piezas aquí y allá (animaciones, jquery ui, .bind() y separando el comportamiento de la presentación). Finalmente, o bien a) obtiene la experiencia suficiente para poder hacer la transición de nuevas páginas / aplicaciones al 100% de jQuery o b) ganar suficiente dinero para contratar a alguien competente en las secuencias de comandos DOM y enseñar por sí mismo al equipo;)

Answer 5

Imo se trata de lo que prefieras.

Microsoft usa los controles de arrastrar y soltar, como el panel de actualización, donde el jQuery se escribe a mano y, en mi experiencia, ofrece un mayor grado de flexibilidad.

JQuery parece ser el marco de elección en este momento para las secuencias de comandos DOM y AJAX, simplemente hace que las tareas relacionadas con JavaScript sean mucho más rápidas y fáciles de implementar.

Answer 6

Si bien el kit de herramientas AJAX de Microsoft es conveniente y simple de colocar, es fácil golpear rápidamente las barreras cuando quiere hacer algo más complicado de lo que diseñó. Si está interesado en aprender los entresijos de AJAX con una biblioteca amigable, JQuery es el camino a seguir. Este conocimiento se traducirá en múltiples plataformas; por ejemplo, si su equipo decide usar Django, Ruby on Rails, etc., ya tiene a JQuery como su kit de herramientas AJAX. Esto es especialmente cierto si alguna vez planea pasar de ASP.NET a ASP.NET MVC para el cual Microsoft ha denominado a JQuery el kit de herramientas de javascript oficial del lado del cliente.