Se hace camino al andar...

He estado leyendo esta noticia de javaHispano en donde se habla sobre Backbase, y me ha hecho pensar en AJAX, y en como puede ser problemático en determinados casos que explicaré a continuación.

Antes de nada, me gustaría comentar que la demo de Backbase me ha gustado muchísimo. Es genial ver todos esos efectos, hasta ahora relegados al mundo del escritorio, ejecutándose en Firefox sin ningún problema.

Desde luego, no hay una buzzword en estos meses que esté sonando más que AJAX. El término AJAX ha aparecido de repente y ha convertido las aplicaciones web tradicionales en RIAs (aplicaciones ricas de Internet), incrementando la usabilidad de sus interfaces y haciendo posible el uso de componentes hasta ahora relegados a otros ámbitos. A pesar de que ya sabéis que era algo que existía hace tiempo, lo cierto es que ha sido como un truco de magia, "ahora ves un pañuelo, y ahora ves un conejo".

Pero ojo con la magia, porque siempre hay truco. Y eso es lo que no se debe olvidar. Como sabéis, la clave en AJAX es esconder las interacciones con el servidor, realizándolas en un modo asíncrono de modo que el usuario no se entera de que están pasando cosas. Si a esto le sumamos que el árbol DOM se actualiza dinámicamente, tenemos que se solventa el problema de las molestas transiciones entre páginas. ¿Cuál es el problema entonces, si todo es tan bonito?

El problema es que como en los trucos de magia, las cosas son de un modo diferente al que se ve. Aunque el usuario no lo vea, por detrás se siguen haciendo continuas llamadas a través de la red, como en las aplicaciones web de siempre. El peligro, es que muchos desarrolladores creo que no se están dando cuenta de esto, y están viendo a AJAX como una solución a todos sus problemas, un nuevo paradigma de programación que por fin ha solucionado los problemas de las aplicaciones web, y que hará que todo y absolutamente todo sea web.

Pero señores. Cordura. Como decía en mi charla en la TechBusiness Week (tenéis las transparencias en el post anterior), la web no es necesariamente el mejor lugar para las interfaces de usuario. Ni con AJAX, ni sin AJAX. La web es un excepcional lugar para cierto tipo de aplicaciones, sobre todo las que se han de distribuir a través de Internet, las que necesitan un acceso masivo y heterogéneo de usuarios, o para las aplicaciones que requieren una enorme ubicuidad. Y es que tenemos ejemplos de aplicaciones web modelo de éxito como flickr, amazon, las googles, y muchas más que se os ocurrirán...

Pero sin embargo, como decía en el párrafo anterior, hay muchos casos en los que un interfaz web está abocado al fracaso. No voy a entrar en las ventajas de las aplicaciones de escritorio frente a las web, porque las tenéis en las transparencias que comentaba. En lugar de esto lo que sí que voy a hacer es comentar un ejemplo que ponía en Alicante, y que creo que es descriptivo de uno de los problemas más importantes de las aplicaciones web, y más concretamente de AJAX. Este problema es la necesidad de conexión de las aplicaciones web; y es un problema de AJAX, justamente porque AJAX nos "esconde" esa necesidad, nos "engaña" haciéndonos creer que tenemos todos los datos, y puede hacer que los desarrolladores olviden que realmente las cosas no son tan mágicas como parece. Muchos sabéis que trabajo en ámbitos hospitalarios. Os voy a poner un ejemplo dentro de este mundillo:

En nuestro hospital hay muchas aplicaciones, entre las que como comprenderéis hay algunas bastante críticas. Una de ellas es la de mi amigo Ricardo, la de hemodinámica. Esta aplicación es utilizada por los hemodinamistas para controlar a los pacientes que tratan. Así, cuando un paciente por ejemplo va a ser operado, para que le hagan un cateterismo por ejemplo, quizás por que haya sufrido algún infarto, los hemodinamistas lo que harán será antes de nada abrir la ficha del paciente y comprobar todos los datos: si ha tenido lesiones en las arterias anteriormente, si se le han prácticado más cateterismos, comprobarán los diferentes parámetros (creedme hay muchísimos) de otras intervenciones realizadas sobre este paciente, etc. Si todo está correcto, el paciente entra en la sala y se procede a realizar la intervencion.

Ahora bien. Imaginaros que los hemodinamistas están ya operando al paciente, y que de repente el responsable de la operación ve un problema y necesita corroborar algunos datos. Entonces, ordenará a alguno de los asistentes que vaya al ordenador a localizar los datos que necesita. El asistente se acerca al ordenador, y recorre las diferentes solapas de la aplicación recolectando los datos sensibles. Una vez los va leyendo, se los va comentando al hemodinamista jefe, y la operación continua. Si hay suerte, el paciente saldrá adelante, y habrá un nuevo éxito.

Pénsemos en lo que podría pasar con un aplicación web con AJAX. Desde el punto de vista del usuario, aparentemente todo es lo mismo. A fin de cuentas, es lo que promete AJAX, mejores componentes gráficos y transparencia en el acceso a datos. Sin embargo, la realidad es otra. En este caso, la aplicación necesita estar conectada continuamente a un servidor. ¿Qué sucede si en el momento en el que se necesitan los datos se cae la red?, ¿y si se cae la base de datos?, ¿y si se estropea el cable de red?, ¿y si se cae el servidor de aplicaciones?, ¿y si algún técnico de sistemas se equivoca y desconecta un switch? ¿y si...? En fin, yo creo que se os pueden ocurrir decenas y decenas de posibles problemas que ya hemos vivido. En el caso anterior, no podría pasar nada de esto, porque los cientos y cientos de datos ya están precargados, y los hemodinamistas los tienen a su disposición. Sí, es cierto que pueden pasar otras cosas, pero por lo menos hemos minimizado enormemente el riesgo.

Ese es el peligro que yo le veo a AJAX y que nadie comenta. Todo es muy bonito, todo es muy fantástico, todo es muy drag and drop y muy desplegable, pero por debajo todo sigue igual, y conviene no olvidarlo, y si no, poneros en el pellejo de la persona del caso anterior.

En ámbitos hospitalarios este tipo de casos pasan mucho. Y en otro tipo de ámbitos también. Normalmente las aplicaciones que pueden requerir el tratar muchos datos que ya han sido cargados, y permitir el trabajo con ellos, están destinadas al escritorio. Esto es simplemente porque es el mejor lugar para estas aplicaciones. Las aplicaciones web tienen su sitio. Por ejemplo, el sistema de citas de nuestro servicio de salud es un sistema web, cosa que es absolutamente lógica, y que es un ejemplo de un buen lugar para un interfaz de usuario web.

Bueno creo que he soltado un buen rollo, ¿no?. Así que no sigo más. En resumen: señores, cordura y precaución con lo que usamos, lo que escogemos, y para qué lo escogemos. Que no todo es tan bonito como parece, y que no existe la tecnología "única", sino muchas tecnologías que están ahí para que las utilicemos cuando realmente se necesitan.