Ventajas / Desventajas
Desventajas

• El cliente necesita un navegador que soporte javascript .Hoy por hoy la mayoríade los navegadores soporta JavaScript. Internet Explorer, Mozilla, Firefox, Safari etc… Para esta desventaja tenemos una “excusa” , no estamos hablando de desarrollar páginas web con ajax, sino aplicaciones web, y como toda aplicación tiene unos requisitos mínimos, y siendo este javascript tampoco se discrimina unespectro muy amplio de usuarios.
• El mal uso de ajax/javascript puede mal emplearse sobrecargando el servidor de peticiones ej: Si hacemos que cada milisegundo haga una consulta con una base de datos… al administrador del sistema le pueden surgir instintos asesinos.

Ventajas

• Nos permite diseñar interfaces muchísimo mas dinámicas acercándonos a “aplicaciones de escritorio”.
• La comunicación asíncrona con el servidor nos permite varias cosas que reducen el “peso de la página” / “lineas de código que el cliente tiene que descargarse”
• Campos de select, si las opciones son muchas… no es necesario transmitirlas en la primera carga de la página, podemos producir la lista de opciones cuando el cliente pulse sobre el des plegable. Otra solución es hacer una búsqueda dinámica.
• La navegación por la aplicación mediante ajax nos permite evitar al cliente descargar la cabecera de todos los “documentos”,”pantallas”.Podemos cambiar el contenido de cualquier objeto del DOM dinámicamente ante los eventos que controlamos con javascript.
• No requiere plugins o capacidades específicas de ciertos navegadores.
• Las aplicaciones son más interactivas, responden a las interacciones del usuario más rápidamente, al estilo desktop
• Se reduce el tamaño de la información intercambiada.
• Muchas micro-peticiones, pero el flujo de datos global es inferior

Diferencias en el desarrollo “PRE” ajax / “POST”ajax
Ya sabemos que se puede hacer con ajax, de igual modo conocemos las ventajas que
nos aporta un desarrollo de este tipo y las pegas que ello conlleva, pero ( como todos
os preguntareis… a la hora de programar que diferencias existen haciendo la
aplicación síncrona o asíncrona .
Las diferencias son mínimas por no decir nulas. De cara del programador su trabajo es
el mismo, con la diferencia que las “salidas” de su código ha de estar empaquetada para ( generando un xml ) ser transmitida al navegador cliente. El programador ha de
conocer los identificadores de la estructura de la web para poder inyectar sus respuesta
al lugar adecuado. Estas diferencias podréis verlas mas adelante en la sección práctica de la presentación.

Que hacer / Que NO hacer con ajax
Ajax puede parecernos útil o no , pero como en todos los aspectos de la vida, de nada se puede abusar. Por muy útil, potente o maravilloso que nos parezca no podemos utilizarlo en el 100% de la página sino para pequeños detalles donde aporte novedades y se diferencie del resto de productos.
Tampoco podemos utilizar ajax si nuestro objetivo es la accesibilidad, los requisitos mínimos son “mínimos” pero no podemos confiar a la suerte que todos nuestros clientes tengan un navegador que soporte javascript. Por esto es necesario controlar las personas que entran a nuestra página,
porque de lo contrario se encontraran con una aplicación que simplemente “no hace nada”.
Yo era el primer reacio a utilizar JavaScript, lo odiaba y lo odio pero creo que es la única manera actualmente de desarrollar aplicaciones web siendo estas “lo mas accesible posibles” , desechando flash, DHTML etc…

Límites de Ajax
A mi entender ajax “manda de una patada” los limites de la web muy lejos. Ajax nos permite hacer interfaces tan dinámicas como siempre hemos deseado pero la inaccesibilidad de flash, plugins de java, etc… no nos dejaban llegar.

Por otro lado a nivel “personal” ajax nos permite hacer muchas más cosas a las que estamos acostumbrados. Es por esto y por su “juventud” que es un espacio muy abierto para la innovación. Los limites personales los pone la imaginación de cada uno. Estos limites “personales” pueden sufrir un placaje tecnológico. Nos encantaría poder tener páginas web actualizadas al enano segundo donde todos los visitantes pudiesen intercambiar información y se refrescasen las ventanas de todos ellos mientras suben archivos y editan Bases de datos mientras graban ficheros de configuración. Pero hay que tener presente que del lado servidor, toda esa interactividad supone gastos cuantiosos. Es necesario llegar a un equilibro entreinnovación, recursos y accesibilidad de los clientes.