Ladle: La Historia sobre los Módulos y el Rendimiento

Esta charla tiene 4 secciones. La primera es una breve lección de historia sobre las características de JavaScript que hemos estado echando mucho de menos durante mucho tiempo. Luego hablaremos sobre los módulos de JavaScript, también conocidos como módulos ES6 o ESM. La tercera sección presenta Vite, un nuevo tipo de bundler, seguido de una introducción a Ladle, una herramienta que construimos sobre Vite. Y finalmente, concluiremos con algunas predicciones futuras.

¿Recuerdan cómo se veían los navegadores en 1995? Yo no, pero seguramente eran muy diferentes. No es sorprendente que JavaScript careciera de algunas características cuando fue introducido. La característica relevante para esta charla es la forma en que JavaScript se carga en los navegadores. Hay que usar la etiqueta de script. El código en sí puede estar en línea o apuntar a un archivo. Esto estaba bien hace 15 o 10 años, cuando JavaScript se usaba para agregar un poco de interactividad. Pero cuando construimos aplicaciones modernas de frontend, esto causa algunos problemas graves. Los archivos se cargan y se ejecutan de forma sincrónica y su orden importa. Las variables de nivel superior terminan en el ámbito global, por lo que es fácil que dos bibliotecas no relacionadas causen colisiones de nombres. Cada vez que creamos un nuevo archivo, tenemos que cargarlo a través de una etiqueta de script adicional y vincularlo al ámbito global. No hay una forma fácil de eliminar el código no utilizado.

JavaScript carecía de un concepto de modularización. Esto fue especialmente un gran problema para el JavaScript del lado del servidor conocido como Node.js. Se necesitaba urgentemente un sistema mejor para dividir y encapsular el código. Así que, Node.js adoptó CommonJS. Esta sintaxis debería ser muy familiar para cualquiera que haya trabajado con JavaScript en los últimos años. Aborda muchos problemas, pero no todos. Introduce un concepto de proveedores y consumidores de código. También es toda una filosofía y se utilizó para crear el registro de paquetes más grande para compartir código llamado npm. Permite la carga dinámica de código. Sin embargo, hay algunas debilidades importantes que lo hacen inutilizable para los navegadores. Por ejemplo, hay referencias al sistema de archivos como el uso de dirname. Pero el mayor problema es que la resolución y carga de módulos debe hacerse de forma sincrónica.

Eso bloquearía la renderización en los navegadores y llevaría a experiencias realmente malas. CommonJS fue desarrollado de forma independiente del partido ECMAStandards, por lo que nunca se convirtió en una parte fundamental de JavaScript. Sin embargo, todavía era un sistema mejor que JavaScript jamás tuvo, y los desarrolladores querían usar código de servidor en sus aplicaciones de frontend. Así que se introdujeron los empaquetadores como Webpack. Webpack puede analizar y resolver todos los módulos de CommonJS antes de crear un solo archivo empaquetado que sirve a los navegadores. Esto fue una gran victoria. Los desarrolladores pueden usar CommonJS para dividir el código en módulos y no tienen que preocuparse por el soporte del navegador en él.

Pero aún nos faltaba una forma estandarizada oficial que funcionara en navegadores y otros entornos de ejecución sin herramientas adicionales. Se introdujeron los módulos de JavaScript. Hoy en día, son compatibles con todos los navegadores modernos y entornos de ejecución. Puedes cargarlos estableciendo el atributo type en module. Y la mejor parte es que los navegadores entienden la sintaxis de importación-exportación y cargan módulos adicionales cuando es necesario. Los módulos funcionan de forma asíncrona y no impiden que las páginas sean interactivas. Hay una API de promesas para importar módulos de forma dinámica. El código puede ser fácilmente eliminado. Solo se cargan las partes que se utilizan. Funciona en todos los navegadores y entornos. Y ahora es un estándar oficial.

No me malinterpreten. Aún hay algunos problemas en cuanto a la compatibilidad con CommonJS y el ecosistema existente, por lo que la adaptación puede ser a veces complicada. Sin embargo, está claro que este es el futuro de JavaScript.

Entonces, ¿qué es Vite? Es un nuevo entorno de desarrollo construido sobre el hecho de que los módulos de JavaScript no necesitan ser empaquetados antes de ser servidos a los navegadores. Eso era una parte importante y muy lenta de Webpack. Por lo tanto, el inicio del servidor de desarrollo puede ser instantáneo. Aún se necesita algo de empaquetado y compilación. Muchas bibliotecas existentes deben ser convertidas de CommonJS. También necesitamos eliminar cosas como JSX y TypeScript. Vite utiliza los complementos ESbuild y Rollup para eso. Comparemos el proceso de inicio de Webpack y Vite lado a lado. Este es el enfoque antiguo de Webpack.

Es necesario analizar toda la base de código y resolver todos los módulos antes de crear un paquete. Solo entonces se puede iniciar el servidor y servir el paquete. Cuanto más grande sea tu aplicación, más tiempo tardará en iniciarse.

Por otro lado, Vite inicia el servidor de inmediato y sirve el módulo de entrada al navegador. Dado que el navegador comprende las importaciones siguientes, solo carga los módulos adicionales cuando es necesario. Vite solo necesita realizar un preprocesamiento ligero, como eliminar los tipos de typescript, antes de enviar estos archivos de vuelta al navegador. Sin embargo, no importa cuán grande sea tu base de código, el servidor siempre se inicia al instante y las reconstrucciones incrementales también son muy, muy rápidas.

Nos encantan estos nuevos beneficios de rendimiento, por lo que tenía sentido poner a prueba Vite y utilizarlo como base para una solución alternativa a storybook. Hemos creado una herramienta de código abierto llamada Ladle. Una herramienta para desarrollar y probar componentes React a través de historias, construida desde cero sobre Vite.

Hagamos una demostración. Comenzaremos con una carpeta vacía, así que inicialicemos nuestro proyecto. También necesitamos agregar algunas dependencias como react, react-dom y ladle. Por defecto, Ladle busca la carpeta source. Y específicamente busca archivos que terminen con .stories.dsx. Así que creemos el archivo welcome-stories.dsx.

Las historias también son solo componentes React, pero deben ser exportadas. Así que exportemos primero el nombre de la historia, que exporta un encabezado. Por supuesto, esto podría ser cualquier componente React, por ejemplo, un componente de tu sistema de diseño. Y ahora podemos iniciar Ladle con el comando ladleserve. Esto inicia de inmediato un servidor de desarrollo v8 y esta es la interfaz de Ladle. En el lado izquierdo puedes encontrar tu componente y en el lado derecho hay una navegación que muestra todas las historias descubiertas. Por defecto, se utilizan los nombres de archivo y los nombres de exportación para crear esta navegación. Pero esto también se puede cambiar a través del código mediante los parámetros nombre de la historia y export default título.

Agreguemos algunas historias adicionales para demostrar otras características. Esta historia tiene un botón que no es muy accesible. Como puedes ver, el contraste de color no es bueno. Puedes ejecutar una verificación de accesibilidad haciendo clic en este icono. Y ahora la verificación nos indica que hay una violación y nos proporciona detalles para que podamos depurar y solucionarlo. Otra característica útil es cuando se prueban la capacidad de respuesta y el diseño responsivo.

Te permite establecer diferentes viewports y probar diferentes consultas de medios. A través de este complemento, puedes cambiar el viewport y probar diferentes tamaños. También puedes establecer un tamaño de viewport predeterminado a través del parámetro .meta y width.

Otra característica útil es cuando quieres mostrar y probar diferentes variaciones de un solo componente. En este caso, estamos cambiando el valor de size. Esta característica se llama controles y ahora mismo podemos cambiar esta variable llamada size y podemos elegir entre tres valores diferentes. Como puedes ver, incluso sin tocar el código, podemos ver diferentes variaciones. Y así es como lo configuras en el código a través de la API llamada arquetipos. Defines qué variables quieres hacer dinámicas, defines las opciones y luego se pasa como una prop en la historia misma cuando se puede usar dentro de tu componente. Hay otros tipos de control que puedes usar como booleanos, cadenas, radios. Por lo tanto, esto es muy flexible para cosas como sistemas de diseño cuando quieres mostrar diferentes variaciones de un solo componente, pero no quieres crear múltiples historias.

Otra característica es genial para registrar los controladores de eventos. Por ejemplo, este botón está utilizando un controlador de acción y una vez que comenzamos a hacer clic en él, obtienes esta notificación y te muestra qué evento se disparó y sus detalles. La acción es una función exportada de Ladle y puede ser simplemente pasada a tus controladores. Y hay algunas otras características, como cambiar entre temas claros y oscuros. Puedes cambiar a pantalla completa. Puedes cambiar entre izquierda y derecha y de derecha a izquierda. También puedes previsualizar el código fuente de la historia. Resalta la historia específica y las líneas de código. También muestra la ubicación de la historia. Y finalmente, Ladle expone el punto final meta.json. Esto te proporciona información estructurada sobre qué historias hay en tu instancia. Esto puede ser extremadamente útil para la automatización y las pruebas. Por ejemplo, usamos este archivo para ejecutar un script de playwright que abre cada URL y toma una captura de pantalla. Luego lo usamos para las pruebas visuales de captura de pantalla. Como puedes ver, estos metadatos también exportan información como el ancho. Cuando estableces el viewport predeterminado, no solo se muestra tu historia en este viewport, sino que también se exporta con él, junto en este archivo. Esto puede ser muy útil para la automatización y las pruebas adicionales.

¿Qué es Ladle? Ladle es un complemento de weed, ReactUI y CLI en un solo paquete. Es una dependencia única, por lo que nunca tendrás problemas de versiones entre múltiples paquetes.

No requiere configuración inicial, pero aún puedes personalizar cosas como fuentes, agregar hojas de estilo adicionales o acceder completamente a la configuración de weed. Admite completamente el formato de historia de componentes y funciona como un reemplazo directo de Storybook.

También admite diferentes configuraciones de monorepo y tiene una excelente API programática, por lo que se puede volver a empaquetar como parte de tu biblioteca. Se lanzó a principios de este año y hasta ahora ha recibido excelentes comentarios de la comunidad. Lo hemos estado utilizando para muchos proyectos internos y públicos y hemos visto mejoras de hasta 10 veces en el inicio de los servidores de desarrollo y el reemplazo de módulos en caliente.

Entonces, ¿hacia dónde se dirige ahora el desarrollo de herramientas frontend? Está bastante claro que los módulos no van a desaparecer y con el tiempo dominarán todo. Esto es genial para nuestras herramientas. Podemos omitir algunos procesos pesados antes de enviar nuestro código a los navegadores. Los navegadores pueden hacer la resolución de módulos por nosotros. También son mucho mejores en cuanto al almacenamiento en caché. También hay una tendencia a utilizar otros lenguajes como Rust y Go para compilar JavaScript. Esa es otra gran fuente de mejoras en la velocidad. Visita ladle.dev para experimentar lo que esta nueva generación de herramientas puede hacer y gracias por escuchar.