Un vistaso en su evolucion.

Veamos el porque nace la necesidad de realizar peticiones asíncronas, las primeras ideas, su evolución y finalmente cuales son las soluciones actuales.

Tiempos Oscuros

No existia nada que permitiera realizar peticiones asícronas, esto significaba que cada vez que se enviaba una solicitud al servidor como presionar un enlace o enviar un formulario, se debía recargar toda la página incluyendo sus partes estaticas como la cabecera, pie de página entre otros, adicionalmente se podia apreciar una pagina en blanco hasta que el navegador volvia a mostrar el contenido. Esto como sabran no es la mejor experiencia de usuario, adicionalmente de ser costosa.

Internal Frames

Existe una tag llamada iframe en html que permite cargar el contenido de una página dentro de nuestra página, esto como podran apreciar permitía hacer una solicitud de forma independiente a otra página interna sin necesidad de recargar la página actual, por lo que basado en este comportamiento los antigüos ingenieros de sistemas se la ingeniaron para crear las primeras solicitudes asíncronas.

El proceso era el siguiente:

• Se incluía un iframe con visibilidad hidden en la página.
• capturabamos un evento con javascript de interes y realizabamos la petición al iframe.
• El iframe cargaba la página que tenia javascript para controlar al padre (es decir la página que realizaba la solicitud).

Esto tenía varios problemas, como acomplamiento entre la página y la petición, no se sabia si la petición terminaba correctamente y seguramente abría la puerta a brechas de seguridad.

Primeros Soportes

Los primeros soportes oficiales que se realizaron por parte de los navegadores fueron los objetos XMLHttpRequest y ActiveXObject(“Microsoft.XMLHTTP”) (y tal vez hubieron algunos otras implementaciónes).

Inicialmente era un caos, por que si se quería realizar una petición, se tenía que validar que navegador utilizaba el usuario y de acuerdo a este navegador utilizar una implementación u otra; por lo que en respuesta a esta problematica hubo una exploción de frameworks javascript (como JQuery) que definian su propia forma de hacerlo y el detras de escenario se encargaban de estas validaciones y utilizaban el objeto correcto para ese navegador.

Promesas

Nace un problema de implementación a medida que las aplicaciones se vuelven mas complejas y requieren manejar multiples peticiones sucesivas, es decir una petición tras el exito u error de otras peticiones, por lo que el código empieza a crecer de forma recursiva (es decir un callback dentro de otro callback), lo cual se conoce como el callback hell.

En respueta al callback hell nacen las promesas, las cuales permiten que el código fuente pueda crecer de forma lineal en vez de forma recursiva. Esto se explica en mayor detalle en el siguiente árticulo Promesas Javascript.

Async/Await

Las promesas resuleven el problema de callback hell y el código es mucho mas fácil de mantener, sin embargo no es tan intuitivo de aprender o entender y gracias a esta dificultad nace una forma de encadenar las promesas conocido como Async/Await.

Con esta solución el código fuente conserva la apariencia de código 100% funcional por lo que ya no son necesarios los callbacks, en vez de esto se puede utilizar el clasico try and catch por lo que el código ahora es facíl de aprender, entender y mantener.

En el siguiente árticulo podemos ver un ejemplo comparativo entre encadenar promesas con .then() y como convertirlo a la forma Async/Await Async/Away Javascript

Conclusiones

• Un entendimiento de esta evolución nos permite apreciar lo que toda una comunidad ha trabajado y como las soluciones siempre deben apuntar a ser mas simples de entender y mantener.
• En el desarrollo de una app existente nos podemos encontrar con cualquiera de las implementaciones menionadas anteriormente, y debemos saber cuales son sus bases y como con un par de lineas podriamos actulizar el código sin afectar su funcionalidad.
• La solución predilecta simpre debería ser Async/Await debido a que es la solución mas facíl de aprender, entender y mantener.