A día de hoy yo no tendría duda sobre cual opción elegir, opción que no tiene que ser mejor que la otra. Realmente, yo enfocaría el dilema mas bien desde el punto de vista de aplicación web AJAX (orientada al servicio), o aplicación web convencional (.net por supuesto), con sus postbacks (o callbacks) y sus Update Panels. (Debería de estar penalizado el uso del control Update Panel 
)
Ajax Control Toolkit
Esta opción nos deja en el ámbito de una aplicación web .Net tradicional con controles de servidor, por lo que seguramente tendremos el grueso de la aplicación en el servidor. Con esto no quiero decir que no sea posible tener lógica en cliente, pero si que resulta bastante engorroso trabajar con los controles del ajax control tolkit con javascript. Por otro lado no debemos olvidar que son controles de servidor, y que son muy fáciles de usar, pero que cuando se complica el desarrollo y la web, no se por qué, pero el trabajo se complica. Otro punto es el peso de las librerías, puf, te echan para atrás. Y un punto no menos importante, si por ejemplo tenemos que hacer una modificación de un Extender, digamos por ejemplo el AutoCcomplete, tendremos que generar un nuevo build y añadir la nueva referencia, y rezar por tener problemas de versiones a la hora de realizar el deploy en el servidor. A modo de anectdota, mencionar que un proyecto en el que estuve trabajando, en cual teniamos un Auto Complete Extender customizado, tuvimos problemas de referencias cruzadas entre versiones de librerias, y con el timestamp del build generado del Extender con la fecha del servidor. Hora del Build X , hora del Servidor de despliegue X-6. Solución, cambiar la hora a la maquina de build y realizar un nuevo build con un timestamp de fecha menor que la hora del servidor web.
Resumiento, este grupo de controles a día de hoy solo tienen sentido (desde mi punto de vista) para desarrollos muy rápidos, que tengan una carga en cliente mínima, o aplicaciones .Net convencionales en el que solo se hagan uso de controles de Servidor.
JQuery / UI
Es un salto de calidad y complejidad. Esta claro que si nos decantamos por ellos es porque vamos a hacer uso de jQuery. Tenemos que recordar que jQuery es una biblioteca o framework de Javascript, que permite simplificar la manera de interactuar con los documentos HTML, manipular el arbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la tecnología AJAX a páginas web. (wikipedia). El uso conjunto de jQuery nos ayudara a generar un código limpio y claro y los widget un toque muy profesional a nuestro desarrollo.
La curva de aprendizaje se acentúa, el uso de jQuery es bastante mas complicado que el uso del javascript convencional y el comienzo no resulta fácil, pero una vez que vamos cogiendole el tranquillo el trabajo se simplifica y se acelera, ¡¡¡ y de que manera !!!.
¿Y en que tipo de aplicaciones? cuando? es indistinto, una vez que nos hacemos al trabajo con las librerías, podemos usar jQuery en cualquier desarrollo, haciendo uso tanto de las librerias o UI widgets indistintamente. La última vez que hice uso los Widgets fue en una aplicación con patrón MVP, y actualmente en un nuevo desarrollo, con el mismo modelo se usan las librerías (y no los widgets). La combinación de Controles ASP.Net y jQuery UI funciona perfectamente.
Aunque los tiros en .Net, apuntan al desarrollo de aplicaciones con el patrón MVC (model view controller), y haciendo uso framework del mismo nombre. Pero esto, ya da para otro artículo…… MVC+ jQuery… y es sábado, 9 de la noche y ya es hora de prepararse para salir y cenar por ahí.
Enlaces de interés:
septiembre 7th, 2010 at 23:54
Planteas una buena y relativa pregunta. Relativa, porque todo depende directamente de los requerimientos y objetivo de la aplicación web que desees desarrollar.
Y buena, porque muchísimos colegas de profesión habran buscado post como el tuyo para decidirse, en algún momento de su profesión, antes de iniciar algún proyecto web.
AjaxControlToolkit. Claramente: Para no complicarse y desarrollar rápidamente. No es necesario ser experto en JavaScript. ¿A que coste?: Menor rendimiento. Útil para aquellos proyectos web que no prioricen el rendimiento y sí la velocidad, tiempos de desarrollo. Una muy buena ventaja es la facilidad en la que podemos ir actualizando versiones a lo largo del tiempo sin esfuerzo, ni coste de tiempo.
jQuery. Para aquellos programadores que les guste controlar meticulosamente los scripts que se cargan, la optimización y la alta personalización del código. Aunque es necesario tener altos conocimientos y una mínima experiencia desarrollando con jQuery…
La actualización de versión puede darnos bastantes incompatibilidades según los desarrollos que se hayan hecho.
En mi opinión:
Creo que jQuery es una muy buena opción. Aunque AjaxControlToolkit tiene muchas ventajas que no te dejan indeferente. Con lo que un híbrido/equilibrio entre los puntos positivos de cada uno, sería una muy buena opción, o por lo menos: Una opción a plantear.
septiembre 8th, 2010 at 8:48
JQuery debería de ser la opción a elegir en un mundo ideal, … por desgracia en un equipo de desarrollo real, tienes que ver que es lo que conocen y cuanto tiempo tienes para entregar. Desde luego deberían de poner como training obligatorio para todo desarrollador web JQuery.
Y bueno.. .¿ Silverlight no os lo planteais? Se puede usar tanto como aplicación independiente como incrustado en el HTML.
septiembre 8th, 2010 at 9:18
Totalmente de acuerdo, pueden convivir las dos opciones perfectamente en un mismo proyecto, pero planteando un desarrollo web RIA, desde mi punto de vista, la mejor solucion sería usar el menor numero de controles de servidor, (yo me limitaria a controles de entrada de datos; textbox y dropdownlist).Nada de UpdatePanels y postbacks. Incrementar el uso de los webservices allí donde podamos. pero como bien dice Braulio, esto depende muy mucho del equipo de desarrolladores disponibles.
Otro punto de interesante es customizar un widget de jQuery o del Ajax Control Toolkit. No hay color, crear una extension sobre un control del Ajax Control toolkit me parece un infierno. Modificar un widget de jQuery es mucho mas facil. Facil, bueno, te tiene que gustar Javascript.
Con respecto a los problemos sobre una actualizacion de version de jQuery, no sería menor que sobre una actualizacion del Ajax Control Toolkit, teniendo en ambos casos que testear bien nuestra aplicacion.
Y Silverlight?, para mi sería la primera opción a la hora de incrustar una aplicación RIA dentro de una aplicación web ASP.NET. Primero por compatibilidad y segundo por facilidad en el desarrollo. Me parece también una opción muy interesante incluso a modo de proxy para el acceso a los web services desde cliente.
septiembre 8th, 2010 at 11:29
Veo que más o menos, pensamos lo mismo.
A nivel de rendimiento general de una aplicación web, lo ideal es generar la menor ejecución posible en el servidor (evitar postbacks, nada de updatepanels, desarrollos manuales en JS mediante jQuery para acceder a los WS, evitar controles de servidor, y un largo etc.)…
Todo, naturalmente, dependiendo del objetivo y prioridades del proyecto web a desarrollar.
Creo que os olvidáis de un tema muy prioritario en los portales de internet: SEO – posiscionamiento en buscadores.
Para generar un buen portal de alto rendimiento se debe tener muy en cuenta y saber en que momento ejecutar funcionalidades en el cliente, siempre y cuando no requiera renderizar nuevamente la página para generar nuevo HTML que los motores de búsqueda puedan indexar. Con lo que Silverlight o Flash se descarta de inmediato.
Al cabo del tiempo y trabajando en diferentes tipos de proyectos web, te das cuenta, que una plataforma perfecta que cumpla al 100% los requerimientos, prioridades y necesidades de cada uno: no existe.
Por eso finalmente opto por utilizar lo más óptimo de cada tecnología. Y no sólo yo: Microsoft también sabe que carece de aspectos que jQuery tiene y a la inversa, así que para las nuevas versiones de Framework 4.0, VisualStudio 2010 y AjaxControlToolkit, jQuery esta totalmente integrado.
He realizado actualizaciones de jQuery y AjaxControlToolkit, y te puedo asegurar que jQuery me dió más incompatibilidades, ya que el margen de personalización de scripts es mayor, con lo que la probabilidad de que aparezcan incompatibilidades también.
Os dejo algunos links relacionados con el tema, por si os pudiese interesar:
http://www.josecuellar.net/category/js-ajax/
http://www.josecuellar.net/category/microsoft-asp-net/
¡Salu2!
septiembre 8th, 2010 at 11:59
Lo bueno de JQuery es que Microsoft da soporte oficial (y eso que no es un producto suyo), digamos que reconoce la importancia de estas librerías. La parte negativa de JQuery es que te encuentras con cosas muy chulas, pero que igual no se te ajustan del todo, y personalizarlas a tu escenario puede ser un infierno, por ejemplo me acuerdo de un ejemplo de un ejemplo de ordenación de una tabla, todo muy bonito, hasta que te topabas con una columna fecha, sólo entendía el formato americano.
Sobre SEO, ahí incluso te tienes que cargar en alguno casos AJAX y orientarlo a que le guste a google tu página y su contenido, hay que diferenciar dos tipos de apliaciones las que quieres que google te encuentre, y las que son más de negocio (incluso en un sitio web dos tipos de páginas).
Silverlight y SEO, se pueden hacer cosas para que se indexe contenido, pero es un latazo, y ahí hay que darle la ventaja a HTML, eso sí, siempre se puede combinar en una página HTML (e.g. una gráfica que se actualize en tiempo real es buen candidato para un control Silverlight), otra cosa es un módulo de administración, o un interfaz para realizar pedidos… que no suelen ser candidatos a SEO, y si fuertes para un interfaz rico y mantenible hecho con Silverlight.
Me gusta mucho el punto de realidad que ponéis en los comentarios, a mi me suelen tirar bastantes piedras a la cabeza cuando los comento… el tiempo, el coste, la calidad de tu equipo son determinantes a la hora de elegir un camino o el otro, … ojala todos pudieramos contar con presupuestos infinitos y equipos majos… bueno en ese caso igual estaría yo en la calle
septiembre 8th, 2010 at 12:23
La verdad es que ultimamente estoy un poco viciado pesando casi todo en cliente, e intentando dejar en servidor unicamente logica de negocio y acceso a datos (es lo correcto? pues seguramente no siempore…. pero…). Es por eso por lo que intento descartar aquellos controles llamados de Servidor. Decir que no siempre me es posible, bien por tiempos de desarrollo o porque motivos de arquitectura impuestos, y es en este punto, al usar Ajax Control Toolkit y Extensiones sobre estos, lo que me hace decantarme por la opcion de jQuery Widget.
Además, si Microsoft integra jQuery ya en su version 4 del Framework, me da la sensación de que tiene la batalla perdida en ese aspecto y lo veo mas dedicando esfuerzos a Silverlight y su lucha con Flex.
Con respecto a SEO, poco puedo comentar, ya que me muevo dentro del mundo de las aplicaciones web corporativas y eso queda fuera del ambito de trabajo, pero si es verdad que en este caso Silverlight queda descartado.
septiembre 8th, 2010 at 14:05
La respuesta a la pregunta que plantea este post es bastante sencilla. Si tienes gente capaz de realizar desarrollo web, JQuery. Si no cuentas con programadores web y solamente tienes un puñado de programadores habituados a desarrollar aplicaciones en Windows forms y que no saben nada de desarrollo web, pues no te queda otra que el ir a por Ajax Control Toolkit. Es decir, no es escoger entre esto y esto, sino mas bien, esto son los recursos que tengo y hasta aquí puedo llegar. De hecho esa siempre ha sido la virtud del Ajax Control Toolkit: puedo programar en web con ajax sin tener ni zorra de como funciona todo. El inconveniente que acompaña a esta virtud ya sabemos de sobra cual es.
Respecto a silverlight, mi opinión es que va a ser una gran plataforma de desarrollo de aplicaciones nativas para Windows Phone 7. Pero respecto al desarrollo web, ha nacido muerto. Es como un invitado que llega a una fiesta muy guapo, muy bien vestido, perfumado y repeinado, pero llega a la fiesta cuando ya toda la gente se ha ido y están recogiendolo todo. Con flash-flex intentando buscar alguna manera de justificar su supervivencia ante la llegada de HTML5, creo que la discontinuidad de silverlight en la web está fuera de discusión.
Y tras ver al Explorer9 sacando un 95 en el acid test y con aceleración por hardware para los gráficos en HTML, ha quedado claro que Microsoft es ya también consciente de que el futuro de las aplicaciones web es HTML5, y se han apresurado de sacar (por fin!) un navegador con un motor de javascript rápido, y que respeta los estándares. No veo por tanto ninguna “complementariedad” entre el mundo HTML/Javascript y los plugins tipo flash-flex/silverlight/java-fx. HTML5 ya es capaz de hacer todo lo que se puede hacer con estos, pero con flash/silverlight no puedes hacer todo lo que puedes hacer con HTML5 (debido a sus naturalezas de plugins).
Con HTML5 el navegador se va a convertir en la plataforma de desarrollo de aplicaciones web, y los plugins ya no van a ser necesarios. Lo siento mucho por flash-flex (que me parece que ni para móviles va a valer, visto el penoso rendimiento que tiene en ellos). Silverlight en cambio, si Microsoft hace una buena implementación de él para Windows Phone, puede que tenga una larga vida como alternativa a WPF para dispositivos móviles.