Hace tiempo que encontré el enlace, pero no lo había leído con detenimiento hasta hoy, tras encontrarlo en La Taberna del Turco.

Para los que no controlen mucho el inglés, me permito humildemente hacer aquí una breve traducción/interpretación en castellano:

Errores en el uso de AJAX en una aplicación web

Usar AJAX por ser “AJAX”:

Sabemos que AJAX  es novedad y que a los desarrolladores nos encanta jugar con lo último, pero ante todo AJAX es una herramienta, no un juguete.
Muchas de las implementaciones que encontramos usando AJAX no son realmente necesarias para mejorar la usabilidad o la experiencia del usuario, sino únicamente experimentos para comprobar qué puede hacer AJAX o empeños de ponerlo donde realmente no se necesita.

Hacer inservible el botón de volver atrás:

El botón de retroceder (del navegador) es muy útil en la navegación de una interfaz web. Desafortunadamente, no se lleva muy bien con las aplicaciones Javascript.
Mantener la funcionalidad asociada a este botón es una de las razones para no realizar una aplicación completamente basada en Javascript.

Sin embargo, se debe tener en cuenta que un buen diseño web debe poner al alcance del usuario todo lo que necesita para navegar correctamente por el sitio y nunca depender de los botones o controles existentes en el navegador.

No mostrar inmediatamente señales del progreso de una operación:

Si algo en lo que hacemos clic lanza una acción mediante AJAX, la aplicación debe dar pistas visuales de que algo está ocurriendo (ya que el navegador no lo hará).
Un ejemplo de esto, es la etiqueta roja que aparece en la esquina superior derecha en Gmail mostrando el texto “loading”, cada vez que la interacción con el servidor se hace mediante AJAX.

No pensar en la gente desconectada (offline):

A medida que los limites de las aplicaciones web se van superando, se hace más patente la posibilidad de mover todas las aplicaciones a la web.
La disponibilidad es mejor, el modelo de acceso desde cualquier parte del mundo es genial, el mantenimiento y la configuración realmente fáciles, la curva de aprendizaje de la interfaz de usuario es pequeña.

Sin embargo, la gente que dispone de malas o lentas conexiones a la red o que simplemente no desean estar conectados también deben tener su sitio. Simplemente porque la tecnología avance, no significa que las personas estén preparadas y deseando ir a su mismo ritmo.

El diseño de aplicaciones web debe considerar al menos el acceso offline (desconectado). Con Gmail es POP (con lo que puedes descargarlo en tu cliente de correo de escritorio y leerlo offline), Backpackit tiene integración con SMS, por poner algunos ejemplos. En el mundo empresarial, sus servicios web.

No me hagas esperar:

Las tabs de Firefox, me permiten administrar varias “esperas” a sitios web y normalmente solo tengo que esperar para la navegación en una página.
Las aplicaciones AJAX combinadas con una conexión/ancho de banda, pueden presentar un enorme problema de tiempos de espera al movernos por su interfaz, ya que cada vez que hago algo tengo que esperar la respuesta del servidor.

Enviar de forma insegura información sensible:

La seguridad en las aplicaciones AJAX está sujeta a las mismas reglas que la de cualquier otra aplicación web, excepto que al poder comunicarse de forma asíncrona con el servidor, pueden tender a estar hechas con código frágil y poco seguro.

Es muy importante que todo el trafico que envía/recibe nuestra aplicación sea comprobado para que la seguridad no se vea comprometida.

Asumir que el desarrollo AJAX sólo es para una plataforma:

El desarrollo AJAX es multiplataforma. De hecho funciona con el motor Javascript del IE, con el motor de Mozilla, con el motor de Safari y con otros que pueden convertirse en fuertes opciones.

No es suficiente programar siguiendo los estándares Javascript (sobre todo sabiendo que existe IE), se debe probar la aplicación en el máximo número de plataformas posible. En el desarrollo con Javascript nos encontramos con un serio problema: la implementación defectuosa del motor de JS de Internet Explorer (aunque existen herramientas para ayudar).

Pero cualquier desarrollador ya estará acostumbrado a lidiar con este tipo de problemas (también con CSS por ejemplo).

Olvidar que la aplicación puede estar siendo usada por varias personas a la vez:

Cuando se desarrolla una aplicación web, es necesario tener en cuenta que va ser usada por más de una persona a la vez.
Si la información que se muestra es almacena dinámicamente en una base de datos, asegúrate que esto no te crea “problemas”.

Demasiado código, hace que el navegador sea lento:

AJAX trae una nueva forma de hacer aplicaciones Javascript mucho más interesantes, pero desafortunadamente esto a veces también significa “más código funcionando”.
Más código funcionando, significa más trabajo para el navegador, lo que provoca que en muchas webs con uso intensivo de Javascript, especialmente las que están  mal programadas, necesites la última CPU del mercado para poder navegar por ella.

De hecho, el problema de uso de CPU realmente ha sido un límite para la funcionalidad de Javascript en el pasado y el hecho de tener CPUs más potentes en la actualidad, no significa que el problema haya desaparecido.

No tener un plan para aquellos que no usen o habiliten Javascript:

Según las estadísticas de de uso de navegadores de W3 schools el 11% de los visitantes a una web, no disponen de Javascript.
Así que si tu aplicación web depende por completo de esta tecnología, parece ser que potencialmente has perdido a una décima parte de tu audiencia.

Hacer parpadear o cambiar partes de la página de forma inesperada:

La A de inicio de AJAX viene de la palabra “Asynchronous” (asíncrono). El problema con los mensajes asíncronos es que pueden ser confusos cuando se muestran de forma inesperada.

Los cambios asíncronos en la página deben ocurrir en zonas bien definidas y deben usarse con buen criterio. Los efectos y parpadeos deben estar limitados a esas áreas y deben tener un sentido.

Desde luego lo que no tiene mucho sentido es que volvamos a los tiempos de la etiqueta “blink” de html y a las “webs parpadeantes”.

No usar enlaces que pueda pasar a un amigo o añadir a favoritos:

Otra característica fantástica de los sitios web es que puedo pasar su URL a otra gente, para que puedan ver exactamente el mismo contenido que yo. También puedo guardar en mis favoritos la URL para regresar posteriormente.

Javascript, y por lo tanto AJAX, trae grandes problemas a este modelo de uso. Al generar dinámicamente la página con Javascript en vez de desde el servidor, la url no necesariamente apunta al mismo contenido, y no puede ser usada para lo que estamos acostumbrados.

Esta es una característica que no se debe perder y de hecho muchas aplicaciones AJAX incluyen “permalinks” (urls especialmente generadas) que solucionan este problema.
Algunos toolkits (como por ejemplo dojo), incluyen facilidades para conseguir esto.

Realizando operaciones por lotes de forma asíncrona:

AJAX permite que la edición de campos de un formulario se realice de forma inmediata, pero  puede traer muchos problemas.
Por ejemplo, desmarco una lista de “check boxes”, cada una de las cuales es enviada de forma asíncrona al servidor.

Pierdo mi habilidad para saber el estado en el que se encuentran los cambios en las “checkbox” y el aluvión de indicaciones de cambio de cada checkbox puede ser molesto y desconcertante.

Mover la posición vertical en la página y hacerme perder la situación donde me encontraba:

Otro problema de insertar texto en una página de forma dinámica es que puede afectar al Scroll. Me encuentro felizmente leyendo un artículo o moviéndome por una enorme lista, y una petición Javascript asíncrona decide de repente cortar un párrafo justo encima de lo que estoy leyendo, haciéndome perder la posición.

Obviamente esto es algo molesto y me hace perder el tiempo intentando volver a encontrar la posición donde estaba. Pero evidentemente esta es una forma bastante absurda de programar una página, tenga o no AJAX.

Inventar nuevos “estándares” de interacción con la interfaz:

Un gran error que es fácil cometer con AJAX es: “haz clic en esta cosa nada obvia para conseguir este nada obvio resultado”.
Los usuarios de una aplicación pueden darse cuenta de que cuando haces clic y mantienes pulsado sobre este div, lo puedes arrastrar y dejar permanentemente en esta otra posición, pero eso no es algo que esté por defecto en la experiencia común de los usuarios.

De esta forma se incrementa el tiempo y la dificultad para aprender a usar una aplicación, lo cual es un punto muy negativo para la misma.

Blockear el acceso a la información a nuestras amigas las arañas:

Las aplicaciones AJAX que cargan una gran cantidad de texto sin recargar la página pueden ser un gran problema para los motores de búsqueda.
Volvemos al mismo problema que con la URL y el botó atrás. Si los usuarios pueden llegar a través de los motores de búsqueda el texto de la aplicación debe estar de alguna manera disponible para que lo lean las arañas (spiders) de los buscadores.

Conjuntos de caracteres:

Uno de los grandes problemas al usar AJAX es la carencia de este de soporte para juegos de caracteres.
Siempre deberías establecer el juego de caracteres a usar en el servidor así como codificar todos los datos usados con Javascript.

Usa ISO-8859-1 si tu aplicación sólo usa inglés o español, o UTF-8 si usas caracteres especiales como æ, ø y å.

Nota: Hoy en día, es buena idea usar siempre el juego de caracteres utf-8 ya que soporta una gran variedad de idiomas.

Cambio del estado con enlaces (peticiones GET):

La gran mayoría de aplicaciones AJAX tienden a usar simplemente el método GET cuando realizan peticiones con XMLHTTPRequest.
Sin embargo, los estándares W3C dicen que el método GET debe ser usado únicamente para obtener datos y el POST únicamente para enviar datos.

Aunque esto no representa una diferencia notable para el usuario final, estos estándares deben seguir siendo usados para evitar problemas with robots o programas como por ejemplo el Google Web Accelerator.

No transferir los cambios locales a otras partes de la página:

Al darte AJAX / Javascript tal control sobre el contenido de la página, es fácil enfocarse demasiado en una pequeña zona del mismo y perder la imagen de la página global.
Un ejemplo de esto, es el título de Backpackit.

Si cambias el título de una página de Backpackit, inmediatamente se reemplaza el título, incluso en la zona de la derecha, pero no cambian el contenido de la etiqueta Title en el Head de la página.

Con AJAX debes tener siempre en mente el modelo completo de la página aunque los cambios sean pequeñas y localizados.

Aviso de errores:

En una aplicación tradicional de lado servidor, dispones de visibilidad para cada excepción, puedes guardar registro de cada evento y estadística o incluso guardar y ver (si lo deseas) el HTML que el navegador está mostrando.

Con las aplicaciones en el lado cliente, puede pasar que no tengas ni idea de que algo esta mal si desconoces cómo programar correctamente y guardar esas excepciones (errores) que se producen remotamente (en el navegador del cliente) en tu servidor.

Retorno de la inversión:

A veces AJAX puede incrementar de forma espectacular la usabilidad de una aplicación (un buen ejemplo puede ser la forma de votar usando estrellas en Netflix), pero lo más común es ver ejemplos de caras aplicaciones en lado cliente (rich-client applications) que realmente no mejoran lo que sería su correspondiente versión en HTML simple.

Imitar el comportamiento de navegación del navegador de forma errónea:

Un ejemplo de esto es el sistema de paginación que ofrece en su página inicial Blinklist.
Cuando haces clic, ves que se carga otra página de link, AJAX reemplaza el número de página.

Pero si estás acostumbrado a la experiencia de uso del navegador, probablemente esperes aparecer en la parte superior de la página cuando pulses el botón de siguiente, algo que la aplicación Javascript no hace.

De hecho, BlinkList se anticipa a esto e intenta contractual manipulando tu scroll para llevarte a la parte de arriba de la página. Pero es muy lento, por lo que si intentas bajar, no te deja.
Pero una vez más, esta es una forma absurda de programar una página tenga o no AJAX.

Este artículo fue publicado originalmente en  ingeniuz.com por Manuel Cebrian.