• Opera 7 y anteriores
• Microsoft Internet Explorer para Windows versión 4.0 y anteriores
• Microsoft Internet Explorer para Macintosh, todas las versiones
• Dillo
• Navegadores basados en texto como Lynx y Links
• Navegadores para incapacitados visuales (braille)

AJAX es el acrónimo ingles para Asynchronous JavaScript and XML (JavaScript y XML asíncrono). Es una técnica de desarrollo web que genera aplicaciones web interactivas combinando:

• Document Object Model (DOM) para visualizar dinámicamente e interactuar con la información presentada.
• XML, XSLT para intercambiar y manipular datos.
• CSS para definir el aspecto (look and feel) del documento.
• JSON y JSON-RPC pueden ser alternativas a XML/XSLT
• XMLHttpRequest para recuperar datos de forma asincrónica.
• Javascript como nexo de unión de todas estas tecnologías.

AJAX es un patrón de diseño que propone un nuevo modelo de interacción Web combinando las tecnologías anteriores.

Las aplicaciones web proliferan debido a su simplicidad, pero ofrecen una menor interactividad y usabilidad en comparación con las aplicaciones de escritorio, debido a que la interacción del usuario con una aplicación web se interrumpe cada vez que se necesita algo del servidor.

Varias tecnologías han sido diseñadas para resolver este problema, Java Applets, FLASH, AJAX es una nueva solución que no requiere plugins o capacidades específicas de ciertos navegadores.

DHTML (Dynamic HTML) técnica de desarrollo de webs interactivas combinando HTML, client-side scripting con JavaScript y el lenguaje de definición de estilos CSS. Realmente AJAX es un refinamiento de DHTML y al igual que en AJAX el principal problema de DHTML es el diferente soporte de estas tecnologías en los navegadores y los diferentes tamaños o resoluciones de pantalla de usuarios.

Como el DHTML o LAMP, AJAX no constituye una tecnología en sí, por eso carece de un entorno de desarrollo propio, pero es un término que engloba a un grupo de éstas que trabajan conjuntamente.

El hecho de que el intercambio de datos se realice de forma asíncrona sirve para hacer que las aplicaciones Web funcionen de una manera casi transparente al usuario en términos de comunicación con el servidor.

El resultado es una interfase con mayor respuesta, dado que la cantidad de datos intercambiados entre el navegador web y el servidor web es reducida enormemente. También se ahorra mucho tiempo de procesamiento en el servidor web, ya que una parte importante de dicho procesamiento se realiza en el lado del cliente.

• Las aplicaciones son más interactivas, responden a las interacciones del usuario más rápidamente, al estilo aplicaciones de escritorio.
• Estas aplicaciones tienen un aspecto (look and feel) muy similar a las aplicaciones de escritorio tradicionales sin depender de plugins o características específicas de los navegadores.
• Se reduce el tamaño de la información intercambiada

• Muchas micro-peticiones, pero el flujo de datos global es inferior
• Se libera de procesamiento a la parte servidora (se realiza en la parte cliente)
• AJAX actualiza porciones de la página en vez de la página completa.

En las aplicaciones Web tradicionales los usuarios interactúan mediante formularios, que al enviarse, realizan una petición al servidor Web. El servidor se comporta según lo enviado en el formulario y contesta enviando una nueva página Web. Se desperdicia mucho ancho de banda, ya que gran parte del HTML enviado en la segunda página Web, ya estaba presente en la primera. Además, de esta manera no es posible crear aplicaciones con un grado de interacción similar al de las aplicaciones habituales.

Además en este tipo de aplicaciones Web tradicionales mientras el servidor esta haciendo lo suyo, ¿qué esta haciendo el usuario? Exacto, esperando. Y, en cada paso de la tarea, el usuario espera por más. Obviamente, si estuviéramos diseñando la Web desde cero para aplicaciones, no querríamos hacer esperar a los usuarios. Una vez que la interfaz esta cargada, ¿por qué la interacción del usuario debería detenerse cada vez que la aplicación necesita algo del servidor? De hecho, ¿por qué debería el usuario ver la aplicación yendo al servidor?

En aplicaciones AJAX se envían peticiones vía http(s) mediante eventos, scripts o rutinas al servidor Web, para obtener únicamente la información necesaria, empleando SOAP o algún otro lenguaje para servicios Web basado en XML, y usando JavaScript en el cliente para procesar la respuesta del servidor Web. Esto redunda en una mayor interacción gracias a la reducción de información intercambiada entre servidor y cliente, y a que parte del proceso de la información se hace en el propio cliente, liberando al servidor de ese trabajo. Además esta petición se realiza como proceso de fondo (background), por lo que el usuario no tiene que esperar que el proceso concluya en su totalidad para continuar interactuando con la aplicación. La contrapartida es que la descarga inicial de la página es más lenta al tenerse que bajar todo el código JavaScript.

En los siguientes gráficos podemos ver la diferencia entre utilizar un modelo clásico de aplicación Web y utilizar el modelo de aplicación Web que propone AJAX:

En el modelo clásico, cada vez que queremos cargar una nueva página Web con nuevos datos, hemos de enviar una petición al servidor Web, y éste nos devuelve la página entera, que incluye tanto los datos a mostrar como la presentación de la misma.

Sin embargo utilizando el modelo AJAX, cuando queremos cargar datos nuevos lo que hacemos en enviar una petición HTTP al servidor Web que nos devuelve únicamente los datos a mostrar (en formato XML), no la presentación de la página. Con este sistema lo que conseguimos es reducir el volumen de tráfico entre cliente y servidor, y también conseguimos que no se tengan que cargar páginas HTML enteras cada vez que queremos representar nuevos datos.

Una aplicación AJAX elimina esas paradas en la ejecución introduciendo un intermediario (el motor AJAX) entre el usuario y el servidor. Parecería que añadir una capa a la aplicación le conferiría una peor respuesta, pero en realidad ocurre lo contrario.

En lugar de cargar una página Web, al iniciar la sesión, lo que hace el navegador es cargar el motor AJAX (escrito en JavaScript y normalmente escondido en un marco oculto).

El motor AJAX (AJAX engine) colocado entre el usuario y el servidor web evita el ciclo start-stop-start-stop característico de las aplicaciones web tradicionales y no es mas que un fichero JavaScript que acompaña al HTML. El cual es cargado al inicio de la sesión y tiene una doble responsabilidad, primero generar la interfaz visualizada por el usuario y segundo comunicarse con el servidor en representación del usuario, lo cual ocurre de manera asíncrona evitando que el usuario vea una página blanca o el reloj de arena (de espera) cada vez que realice una acción.

Toda acción del usuario que normalmente generaría una petición HTTP, adquiere la forma de una llamada JavaScript al motor AJAX. Cualquier acción del usuario que no requiera un viaje al servidor (tales como validación de datos, edición de datos en memoria e incluso la propia navegación) es procesada por él mismo. Si el motor necesita algún tipo de proceso en el servidor para generar la respuesta (enviar datos para procesamiento, carga de código de interfaz adicional o petición de datos nuevos) realiza las peticiones de manera asíncrona, normalmente usando el objeto XMLHttpRequest, sin detener la interacción del usuario con la aplicación.

Los mayores desafíos al crear aplicaciones AJAX no son técnicas. Las tecnologías centrales son maduras, estables y bien conocidas. En cambio, los desafíos son para los diseñadores de estas aplicaciones: olvidar lo que creemos saber sobre las limitaciones de la Web, y comenzar a imaginar un rango más amplio y rico de posibilidades.

Por motivos de seguridad las invocaciones a recursos vía HTTP solamente pueden efectuarse a páginas alojadas en el mismo dominio que el de la página que contenía el script. Si queremos que la información de nuestras peticiones no sea visible deberemos utilizar un canal HTTPS.

Vamos a considerar una aplicación web con un formulario que requiere validación en el servidor sin necesidad de refrescar la página completamente. Es decir, realizar un HTTP POST de la página implícitamente.

1. Un evento ocurre
2. Un objeto XMLHttpRequest es creado e inicializado
3. Se realiza una invocación remota a través del objeto XMLHttpRequest
4. La petición es procesada por el servidor el cual devuelve un documento XML con el resultado.
5. El objeto XMLHttpRequest invoca la función callback() y procesa el resultado.
6. El árbol DOM de la página web es actualizado.

if (method == 'GET') {

ajax.onreadystatechange=function() {

if (ajax.readyState==4) {

}

}