jueves, septiembre 28, 2006

¿Como decidir que framework de AJAX se debe utilizar?

AJAX se ha convertido en una de las innovaciones tecnológicas con más crecimiento en el último año. Este crecimiento ha traído la proliferación de una gran cantidad de middleware (frameworks, librerías y toolkits) que permiten hacer uso de este conjunto de tecnologías de forma más fácil.

Pero la gran cantidad de middleware existente hace que sea difícil saber cual tener en cuenta al momento de tomar una decisión en el desarrollo de un aplicativo.

La importancia de utilizar un framework, toolkit o librería radica en la reutilización de funcionalidad, ya que lo más importante de usarlos o no es poder evitarle al desarrollador los problemas de trabajar con Javascript, DHTML y XML todo junto.

Para poder saber como utilizar estos componentes reutilizables. Debemos tener en cuenta que tipo de middleware se ofrecen en el mercado para trabajar con AJAX. Estos middleware pueden ser frameworks, librerías de widgets [1]o toolkits.

Los primeros, como Gamma lo indica, son “un conjunto de clases cooperando que hacen uso de un diseño reusable para una clase de software especifico”. En este caso, los frameworks AJAX proveen simplemente el uso de AJAX en una aplicación Web y ocultar el trabajo con Javascript y XML.

Los toolkits, son un conjunto de clases relacionadas y reusables que proveen funcionalidad de propósito general; en este caso, los toolkits de AJAX permiten el trabajo con AJAX en general y no se concentran en un tipo específico de aplicaciones o software.

Por ultimo, las librerías de widgets son un conjunto de etiquetas y widgets predeterminados de los cuales se puede hacer uso en una aplicación, son fáciles de usar pero no son tan flexibles como los frameworks y toolkits.

Existe otra clasificación para los middleware de AJAX, esta es por la plataforma objetivo del middleware. Un ejemplo de esto es que existen frameworks AJAX java centric, dot NET centric, Struts centric, JSF centric, PHP centric, etc.

Para poder decidir que framework de AJAX se debe utilizar debemos comparar que tan beneficioso es para el desarrollo. Pero lo importante es definir los criterios que nos permiten esa comparación. Aquí miraremos los criterios y definiremos cuales son los mejores frameworks o toolkits a utilizar.

  1. Plataforma.

La plataforma en la cual esta soportado el middleware es el primer criterio que se debe tener en cuenta para la selección. Para Java se pueden tener en cuenta (aunque no son los únicos) DWR (Direct Web Remoting), Echo2 en cuanto a frameworks o Dojo, Script.aculo.us, Prototype, AJAXLib por parte de los toolkits. En .NET existen frameworks como AJAX Engine, ATLAS, ConfortASP .NET, MagicAJAX .NET, Telerik. Y para php existen AjaxAC, Zoop.

  1. Orientación.

Para Java, podemos tener frameworks que se especializan para una tecnología especifica, como JSP, JSF, TagLibraries, Struts.

  1. Programación Directa o Indirecta.

La programación de AJAX puede ser indirecta o directa. En la programación indirecta se permite la actualización del contenido de la página sin programar en AJAX directamente.

Concretamente, la programación directa de AJAX, significa tratar con scripts en el cliente, DHTML, métodos delegados, despliegue en el lado del cliente, etc.

Las soluciones de programación indirecta de AJAX, permiten actualizar proyectos ya creados, mientras que las soluciones de programación directa; son mas recomendadas para proyectos nuevos, y permiten mas control del código (tu sabes que se está haciendo).

  1. Soporte de controles no AJAX.

Otra característica importante es que se soporten controles no AJAX y se mejoren con características AJAX, es decir, que no solo provean controles con AJAX incluido sino que se pueda extender el uso de AJAX a otros controles. Las librerías con controles preestablecidos, son útiles para características muy simples o cuando el equipo desarrollador tiene un conocimiento bajo o nulo de AJAX.

  1. Soporte de Múltiples Navegadores

Dependiendo de las condiciones del cliente, se puede establecer que se requiere portabilidad en varios navegadores, esto hace importante que se deba utilizar un framework o toolkit que soporte las necesidades del cliente.

  1. Trafico de Red.

Es necesario saber que tanto tráfico el framework o toolkit envía y recibe en una petición. Esto puede afectar directamente el desempeño del aplicativo. Por ejemplo, para una prueba de concepto con el Hello World, el framework con más consumo de tráfico de red para .NET fue ATLAS y el menor fue FastPage.

  1. Instalación.

Muchos de estos frameworks son tan fáciles de instalar como montar archivos .jar o assemblies, pero otros son mucho más difíciles por las dependencias requeridas para que el framework funcione correctamente. El grado de dificultad para instalar se convierte en un factor clave para la selección del framework.

Cuando se debe trabajar con AJAX, no podemos determinar un solo middleware que sirva para todo tipo de proyectos, por eso se debe tener en cuenta las características de la funcionalidad que se quiere desarrollar en AJAX para poder elegir el framework correcto. Igualmente, no se trata de tener 2, 3 o 4 frameworks en el mismo proyecto, sino tratar de cubrir el mayor número de características a implementar con AJAX en el mismo aplicativo.

Para la plataforma Java, cuando se quiere tener control total sobre el código que se quiere implementar del lado del cliente, lo mejor es optar por un toolkit como Dojo o Script.aculo.us.

Si tenemos un aplicativo que requiera implementar AJAX con controles estándar (textbox, input) la mejor opción es una librería de Widgets, Ej., AjaxTags. Para el trabajo con Struts o JSF se puede trabajar con Dojo o con un framework específico para la tecnología como AjaxAnyWhere o ajaX JSF Framework; o trabajar con la última versión de Struts (Shale).

Para el trabajo con .Net los frameworks más recomendables son ComfortASP y ATLAS.

Por último y para recordar, Internet Explorer presenta una fuga de memoria cuando se trabaja con scripts en el cliente y DHTML. Dependiendo del framework que se utilice, la fuga de memoria es diferente.



[1] Window Gadget. Término genérico para referirse a los elementos de una interfaz gráfica con el usuario, como botones, barras de desplazamiento, campos de entrada de texto, etc.