Pros y contras de MS Ajax vs. jQuery en una aplicación ASP.NET MVC?

Question

Ahora que RC1 está listo, tengo que decidir de una vez por todas si se usan las bibliotecas MS Ajax o simplemente jQuery para las solicitudes AJAX. La aplicación es una nueva aplicación. Esencialmente, la forma en que decidiré es si obtengo o no algún beneficio significativo de las bibliotecas de Microsoft que no obtendría de jQuery. Ya tengo cargando jQuery y me preocupa la sobrecarga adicional de tamaño de archivo más que cualquier otra cosa.

Por lo que yo sé, la única ventaja es que hay ayudantes como Ajax.BeginForm, pero quizás esto funcione con jQuery en algún momento. También me contó hoy un amigo del empleado del gobierno que la biblioteca de MS Ajax tiene MUCHOS errores, lo cual me preocupa.

Con Microsoft ahora oficialmente befriended jQuery No estaría demasiado preocupado por que hagan algo en el futuro para dejar jQuery en el polvo mediante la mejora de sus propias bibliotecas.

Realmente no sé mucho sobre exactamente lo que MS Ajax realmente hace por mí. ¿Hay ciertos pros y contras? ¿O es solo 90% de hinchazón para soportar 'panel de actualización'?

También me parece muy interesante que el libro ASP.NET MVC in Action simplemente salta sobre las bibliotecas MS Ajax y salta directamente a jQuery:

En este capítulo el lector examinar cómo la técnica AJAX es aplica a ASP .NET MVC en una forma más perfecta que con formularios web. El lector verá cómo aprovechar una biblioteca de javascript , cada vez más popular y liviana, llamada jQuery.

(de free sample capítulo sobre AJAX)

agradecería mucho escuchando a nadie acerca de sus experiencias Workin con ambos, EXPECIALLY en las siguientes preguntas adicionales:

• es fácil convertir código entre las dos bibliotecas, suponiendo que los requisitos de ajax son relativamente simples
• se depura notablemente mejor o más rápido en la biblioteca
• ¿Alguien sabe cómo está progresando ASP.NET 4.0 y cualquier plan anunciado para la biblioteca AJAX que podría ser beneficioso para MVC?
• ¿Qué podría hacer MS AJAX por una aplicación MVC además de enviar solicitudes y pegar la respuesta en un DIV?
• ¿cómo hago el equivalente a Ajax.BeginForm(...) y uso jQuery?
• ¿Cuál fue tu problema de una manera u otra?
• ¿con qué la mayoría de la gente está usando?

Answer 1

Personalmente, me quedaría con JQuery. MS AJAX es bastante pesado en términos de tamaño y puedes hacer mucho con JQuery. En cuanto a si es fácil convertir código, bueno, depende de la cantidad de material MS AJAX que esté usando. No creo que haya realmente una diferencia apreciable en la depuración de uno a otro. Tendrás una comunidad más grande de usuarios de JQuery para obtener recursos.

Answer 2

Puede (y yo uso) usar ambos dependiendo de la necesidad. Cuando quiero que un formulario en particular no sea compatible con JavaScript Y estoy generando contenido en el servidor, usaré MS AJAX a través del AjaxHelper. Construye todo lo que necesito en el lado del cliente para manejar el navegador no habilitado para javascript. Solo necesito detectar AJAX/no AJAX en el controlador y devolver una vista parcial o total dependiendo. Si necesito usar AJAX como parte de un complemento (digamos autocomplete), entonces usaré jQuery. El punto es que utilizo la herramienta que mejor se adapta (más fácil de implementar) para mí. De acuerdo, la mayoría de mis aplicaciones se ejecutan en una intranet, por lo que estoy menos preocupado por el tamaño de las descargas.

Answer 3

También encontré la jQuery announcement acerca de la EM que incorpora la biblioteca

parecer:

Además Microsoft será el desarrollo de controles adicionales, o widgets, para ejecutar en la parte superior de jQuery que será fácil desplegable dentro de sus aplicaciones .NET. jQuery helpers también se incluirá en la parte del lado del servidor del desarrollo de .NET (en además de los asistentes existentes) proporcionando funciones complementarias a capacidades ASP.NET AJAX existentes.

Así que estoy pensando que es bastante probable que terminen teniendo ayudantes de jQuery que reflejan exactamente los ayudantes de AJAX para las cosas de MS.

Creo que la solución que voy a tomar es usar Html.BeginForm, y luego interceptar el botón de enviar para usar jQuery. No estoy especialmente preocupado por las personas sin la funcionalidad de pérdida de JavaScript, pero no es mucho más difícil de hacer, así que también puedo.

Answer 4

JQuery es mucho más fácil de codificar que Ajax asigna los problemas de sobrecarga que se pueden remediar agregando más memoria en lugar de hacerlo por código de línea de flujo. Ajax simplemente no tiene ningún sentido para mí, aunque solo soy un principiante en eso. Después de lidiar con la sintaxis Ajax excesivamente críptica, jQuery es como un soplo de aire de freash.

Answer 5

Bueno, hay una cosa que encontré con MS Ajax framework que no se puede hacer elegantemente con jQuery. Los controles de usuario construidos MS Ajax están muy orientados a objetos. Esto no se puede hacer fácilmente con jQuery. Por ejemplo, supongamos que está creando un control de usuario de "dirección", que tendrá la dirección1, la dirección2, la ciudad, el estado, el código postal y el país. Puede construir este control con jQuery y Ajax, pero el beneficio que proporciona la biblioteca Ajax es que compartimentará el control de la dirección. Puede definir una función "reset()" en ese control que restablecería el contenido del control de dirección. Digamos que quiere "reset()" para establecer la dirección1, la dirección2, la ciudad en la cadena vacía pero el estado en "AL" y el país en EE. UU. Define el código para el control Ajax en el archivo (.js) y esa función se asociará con el control de su dirección. Lo mismo no es posible con jQuery. Cualquier función que defina tendrá un alcance global y no existe una manera fácil de vincular esa función Control de dirección. ¡Bien puede llamar a la función "restablecer" en el control de cuadro de texto en el formulario!

Así que si quieres crear un objeto puro orientado a controles de usuario, entonces supongo que una mejor opción es utilizar MS Ajax framework.