Una historia de JavaScript (II)
Y entonces llegó Webpack, ES6 y ReactJS. Y todo cambió.
Nuestra primera parte de la historia de JavaScript terminó con la llegada de los primeros frameworks para crear aplicaciones web. Pese a las mejoras que introdujeron, todavía tenían que lidiar con las complicaciones inherentes al lenguaje y a la ausencia de librerías que permitiesen llevar a cabo algo más que automatizaciones (Grunt, Gulp…).
Esta situación dio un giro de 180 grados entre 2013 y 2015. Si tuviéramos que preguntarnos qué provocó la revolución del desarrollo web, deberíamos dirigir sin dudar la mirada a esos años. Webpack, la especificación ES6 de JavaScript y ReactJS los cambiaron todo.
Webpack
Hasta la publicación de Webpack, no había forma de entender los recursos de una web como un todo. Las imágenes, fuentes, archivos CSS y, por supuesto, JavaScript eran compartimentos estancos. Por ejemplo, si queríamos usar una imagen dentro de un archivo JavaScript, era nuestra responsabilidad especificar su path dentro del proyecto.
document.getElementById("myImg").src = "happy-dog.jpg";Y si un archivo CSS estaba asociado específicamente a un widget de JavaScript, teníamos que asegurarnos de que ambos archivos eran cargados en el HTML final.
<html>
...
<link rel="stylesheet" href="widget.css">
...
<script type="text/javascript" src="wdiget.js"></script>El caos estaba servido. Si a eso le sumamos que cada archivo de JavaScript incluido en el DOM compartía variables con el resto de archivos, la fiesta estaba servida.
// first.js
var colorCodes = {
back : "#fff",
front : "#888",
side : "#369"
};
// second.js
alert(colorCodes.back); // alerts `#fff`Sí, había “task runners” como Gulp o Grunt que nos permitían automatizar ciertas tareas (minificar, generar el HTML, …), pero eran incapaces de ver los componentes como parte de un un todo.
Y entonces llegó Webpack para, por fin, permitirnos relacionar elementos, independientemente del tipo que fuesen. Su idea era muy sencilla: entender cada elemento (ya fuera una fuente, un archivo CSS, una imagen o un archivo JavaScript) como un módulo y generar a partir de ellos los “assets” finales de la aplicación.
Webpack era capaz de ver las dependencias entre los diferentes elementos y generar un árbol de dependencias que permitiese optimizar la generación de los estáticos. Y gracias a la sintaxis import de ES6, las variables definidas dentro de cada uno de los archivos permanecía aislada del resto.
En resumen, algo tan habitual en 2022 como:
import bg from './bg.jpg';
import styles from 'Component.module.css';
import View from './View';no fue posible hasta que apareció esta librería.
ES6
Para que Webpack pudiese mostrar todo su potencial necesitó que JavaScript estandarizase la forma de definir módulos, es decir, compartimentos estancos dentro de la aplicación cuyas variables fueran invisibles para el resto.
No sólo eso. Hasta 2015 JavaScript todavía vivía anclado en una sintaxis antigua que ponía enormes dificultades a la hora de trabajar con objetos, cadenas de texto o código asíncrono.
La publicación de ES6 o ECMAScript 2015 resolvió todos estos problemas de golpe:
Aparecieron las arrow functions para facilitar la creación de funciones de una línea y simplificar el uso de
this.La clases fueron incorporadas al lenguaje.
Aparecieron los template strings, los cuales nos permitían interpolar variables sin necesidad de recurrir al operador
+para concatenar strings.Se añadieron
letyconstcomo una nueva forma de definir variables.Las promesas llegaron por fin al lenguaje (y sí, también los generadores).
Se incluyeron azucarillos sintácticos como la desestructuación, el operador rest/ spread,. etc para trabajar con objetos.
Y se permitió la creación de módulos mediante la sintaxis
import/export.
Si a estas alturas es imposible resumir lo que significaron cada una de estas novedades por separado, imaginad lo que supuso la llegada de todas ellas de golpe. El lenguaje y la forma en que lo usábamos para escribir aplicaciones había cambiado para siempre.
Babel
Todas estas características molaban mucho. El problema es que los navegadores no las acogieron inmediatamente, sino que se tomaron su tiempo en integrarlas o directamente prefirieron no hacerlo (ejIEm). Teníamos un Ferrari en nuestras manos limitado a 80 km/h.
Para resolver este problema apareció Babel, una librería que transpilaba código “nuevo” a código antiguo, de modo que teníamos que preocuparnos de si la “build” final sería compatible con los navegadores donde iba a correr.
Por supuesto, se integraba a la perfección con Webpack, por lo que ambas formaron un dúo que nos permitieron aprovechar al máximo todas las novedades que ES6 trajo consigo.
ReactJS
Webpack y ES6. Ahora sí teníamos todas las herramientas para crear sistemas que exprimieran el lenguaje. Podíamos importar archivos CSS dentro de JavaScript, declarar promesas para librarnos de los callbacks y ya no teníamos que lidiar con los problemas de la declaración de variables con var.
El problema era que por aquel entonces no teníamos muy claro dónde debía vivir el estado de nuestra aplicación. O más bien. No nos importaba. Que levante la mano quien no haya recurrido a los atributos data- para dejar valores en el DOM que luego pudiera leer JavaScript.
Resulta curioso, porque algo tan importante como es tener claro dónde consultar el valor de un elemento no nos preocupaba. Bueno, al menos a mí 🫣. Por ejemplo, el estado de un campo en el formulario vivía a veces en el DOM, otras veces en JavaScript y otras… pues a la vez.
ReactJS llegó para poner orden a esto. Su propuesta fue la siguiente: "A partir de ahora, el estado vivirá exclusivamente en JavaScript, y siempre que cambie, pintaremos de nuevo la interfaz”. En resumen, sólo había un camino de ida para el estado, de JavaScript hacia el HTML. Nunca de vuelta.
La vista pasó a ser una función del estado. f(s) = v.
Tras esta idea aparecieron dos elementos que conformarían los pilares básicos sobre los que se asentó React:
Los componentes, que permitían partir una interfaz en elementos más pequeños con su propio estado y ciclo de vida.
El Virtual DOM, encargado de optimizar el proceso de “repintado” de la vista en función de los cambios producidos.
Es cierto que frente a la idea propuesta por React, frameworks como Angular 2 siguieron apostando por el estado de doble sentido. Sin embargo, tener un único sentido para las modificaciones del estado simplificaba enormemente los casos de uso, motivo que puede estar detrás de la espectacular acogida que tuvo la librería.
Componentes y vistas
El camino que abrió React motivó la aparición de otros frameworks y librerías que apostaron por la idea de partir una interfaz en componentes.
La idea básica detrás de ellos era enfocarse en resolver el problema de la representación de la vista de una forma óptima.
Esa fue la razón de que ReactJS, por ejemplo, no incorporase ningún elemento adicional como un enrutador o su propio sistema para gestionar peticiones asíncronas. Acotar el alcance del problema a la vista permitía centrar los esfuerzos en mejorar el rendimiento que suponía pintar interfaces dinámicas con un estado sujeto a cambios.
Esta misma simplicidad permitió que fuese mucho más fácil adoptar estas librerías. Si querías crear un widget o web con una sola vista el desarrollo a partir de ellas era extremadamente simple.
En el otro extremo de la balanza, dejar el resto de elementos de una web a la decisión del desarrollador provocó que cada proyecto estuviera organizado de una forma y usase sus propios “estándares”. No era raro abrir dos proyectos de React y encontrarnos con dos estructuras de carpetas, librerías de enrutado o estándares de código distintos.
Además, pese al auge de estas librerías, había otro gran problema. El SEO. Las webs construidas sobre ellas delegaban por completo la generación de la vista a JavaScript. Esto significaba que las arañas de Google y compañía veían al llegar una página en blanco, dado que no ejecutaban sus scripts. Podías tener la mejor web del mundo, que si Google no te veía no eras nadie.
Estos dos problemas dieron pie a la última parte de nuestra historia: la aparición del Server Side Rendering y de una nueva generación de frameworks que, desarrollados sobre estas librerías, establecían un patrón común para crear aplicaciones.
🙏🏻 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 y último episodio hablaremos de la aparición de Next, Nuxt , y el resto de frameworks para el desarrollo de aplicaciones web que están llamados a marcar el paso en los próximos años.
💛 ¡Muchas gracias por leerme! Suscríbete gratis para recibir nuevas publicaciones y apoyar mi trabajo.