Una historia de JavaScript (I)
Un repaso por etapas de los principales frameworks basados en JavaScript y cómo han ido influyendo en la forma en que construimos aplicaciones web.
Se dice pronto, pero ya van más de 14 años sumergido en el desarrollo web. Esto significa que he podido vivir de primera mano la evolución que ha experimentado; desde los tiempos en que definíamos la estructura con tablas (sí, etiquetas table tal y como lo oyes) hasta la aparición de frameworks que nos permiten hacer cosas que eran impensables unos años atrás.
Por el camino también he vivido intensos debates. ¿Dónde debe ir el CSS? ¿Y el estado? ¿Angular, React o Vue? Y, por supuesto, el vértigo de sentir que desde hace unos años es imposible mantenerse 100% al día.
Recuerdo que uno de mis proyectos serios lo desarrollé con Drupal (PHP). Eran los tiempos de los grandes monolitos, en los que el servidor se encargaba de procesar la petición y generar el correspondiente HTML con todo el CSS y JS necesario.
Técnicas como las que usaba Tuenti para permitir navegar sin recargar la página parecían magia; el común de los mortales nos contentábamos con usar las llamadas AJAX (Asynchronous JavaScript And XML) para a enviar formularios y filtrar listas.
Y entonces apareció AngularJS. Y todo cambió. Al menos pa mí.
Hoy quiero repasar contigo el proceso de cambio que nos ha llevado hasta aquí. Ninguno de nosotros creo que podamos adivinar el futuro del desarrollo web, pero conocer el pasado puede que nos ayude a tomar consciencia de los cambios que impulsaron los grandes saltos.
JavaScript. Los inicios
JavaScript fue lanzado en 1995 con el objetivo de proporcionar un lenguaje que permitiese definir interacciones complejas con el navegador.
En sus primeros años JavaScript tuvo que enfrentarse a las distintas implementaciones que hacían los navegadores de este lenguaje así como a las limitaciones que presentaba a la hora de trabajar con los elementos del HTML.
Sin embargo, dos cambios le devolvieron la popularidad y el interés de la comunidad:
La estandarización del DOM y su adopción por la European Computer Manufacturers 'Association (ECMA).
La aparición del objeto XMLHttpRequest que definía una manera común de realizar llamadas al servidor sin recargar la página (AJAX).
A partir de ese momento surgieron librerías que simplificaron enormemente el uso de JavaScript. JQuery, como imaginarás, es la más famosa. No sólo proporcionaba multitud de métodos que hacían más fácil interactuar con el DOM, también resolvía el problema de incompatibilidades entre navegadores. Cosas tan básicas como la gestión de eventos eran tratadas de forma distinta en Internet Explorer y Netscape, lo que obligaba a adaptar manualmente el código al navegador en donde se iba a ejecutar.
Sin embargo, el uso de JavaScript se reducía a la implementación de widgets y elementos de interfaz. La lógica de la aplicación y otros aspectos como el enrutado o la generación del HTML mostrado todavía vivían en el lado del servidor. Tampoco existía el concepto de módulos lo que significaba que todo el JavaScript era global (salvo que recurrieras a patrones como los módulos basados en IIFE’s). Y, por supuesto, tampoco contábamos con herramientas para empaquetar el código, realizar tareas sobre él (minificarlo, por ejemplo) o gestionar paquetes. Grunt, Bower o NPM tardaron bastantes años en aparecer. De Webpack ni hablamos.
Esta situación contrastaba con la que permitían las aplicaciones móviles. Objective-C en iOS y Java para Android proporcionaban las herramientas necesarias para definir la lógica de la interfaz en el lado del cliente. También aseguraban un sistema de navegación que no implicaba múltiples recargar y, lo más importante, la comunicación entre la aplicación y el servidor se reducía al intercambio de información para generar las vistas. El servidor quedaba liberado de generar la parte de la vista.
Para cuando entramos en la segunda década del siglo XXI algo cambió. Google demostró que era posible construir aplicaciones de escritorio usando páginas web (Google Docs, GMail…) y redes sociales como Facebook o la ya mencionada Tuenti comenzaron a implementar funcionalidades más complejas como chats o el uso intensivo de llamadas AJAX para gestionar la vista y el enrutado de la aplicación.
No obstante, la mayoría de las aplicaciones webs seguían limitadas a tener una carpeta assets donde depositar el JavaScript y las librerías. No había una forma estandarizada de manejar el estado de la vista ni los datos que mostraban.
Hasta que aparecieron los primeros frameworks.
Los primeros frameworks
La llegada de 2010 supuso la aparición de distintos frameworks que permitían escribir aplicaciones web completas en el navegador. El listado es bastante amplio aunque, probablemente, casi ninguno de ellos te suene si llevas menos de 5 años dentro de este mundo:
Estos frameworks fueron los encargados de abrir el camino para todo lo que vendría después. Su principal objetivo era popularizar el concepto de SPA (Single Page Applications), es decir, webs donde, al igual que ya sucedía en las aplicaciones nativas para móviles, la comunicación con el servidor se limitaría al intercambio de información.
Recibieron numerosas críticas, muchas de ellas fundamentadas. Eran los tiempos en los que el SEO era una piedra angular de cualquier proyecto y, desarrollar aplicaciones basadas por completo en JavaScript, suponía que los crawlers no pudieran inspeccionar la página. Además, los navegadores no eran tan veloces como pueden serlo ahora, de modo que el rendimiento era significativamente peor comparado con el sistema tradicional basado al 100% en el servidor.
Estos años también supusieron el lanzamiento de herramientas que revolucionaron la forma en que construíamos la carpeta assets que albergaba el CSS y JavaScript de la aplicación.
NodeJS fue liberado en 2009. Al año siguiente se publicó la primera versión de NPM, el famoso gestor de paquetes que vino a terminar de un plumazo con la descarga manual de librerías y el problema que suponía el control de versiones. CommonJS y AMD competían para establecerse como la manera estándar de definir módulos en las aplicaciones y así evitar que todo fuera global. Aparecieron los primeros preprocesadores de CSS como SASS y LESS. Y, herramientas como Grunt o Gulp nos permitían definir tareas para construir la versión final de nuestros assets; ambos serían a la postre los precursores de WebPack.
De esta época creo que todos aprendimos muchísimo. Siempre digo que a día de hoy puedo llamarme fullstack gracias a que viví este periodo de innovación en el que poco a poco backend y frontend se iban separando. Aún así, todavía lidiábamos con numerosas limitaciones:
JavaScript no era un lenguaje maduro como puede serlo a día de hoy. Por ejemplo, carecía de una forma óptima para lidiar con todo ese código asíncrono que poco a poco comenzaba a ser el núcleo de las aplicaciones.
Como ya he comentado, el rendimiento de las SPA’s todavía no era el esperado. Sin herramientas como WebPack, estábamos obligados a enviar la gran parte del código en la primera carga, lo que suponía mayores tiempos de espera hasta que el usuario podía comenzar a usar nuestra aplicación.
HTML también comenzaba a mostrar sus limitaciones al no implementar un sistema de plantillas que permitiera separar en componentes cada una de las partes de la interfaz.
Y, pese a la aparición de Grunt o Gulp, se hacía necesario herramientas más poderosas que permitiesen trabajar de forma conjunta con los distintos tipos de assets que componen una aplicación.
Pese a todo, fue una época increíble, llena de avances que permitieron vislumbrar el potencial que encerraban los navegadores y la separación de conceptos.
Entonces, alguien redescubrió el átomo. Apareció la primera versión ReactJS.
🙏🏻 Gracias a Garaje de Ideas
Los amigos de Garaje de ideas patrocinan Latte and Code y buscan talento: http://bit.ly/garaje-tech-talento
Continuará…
En el siguiente episodio hablaremos de la aparición de React, la revolución que supuso entender las interfaces como un conjunto de componentes y el desarrollo de la segunda generación de frameworks para construir aplicaciones web.
💛 ¡Muchas gracias por leerme!