Lleva Node.js a tu navegador con WebContainers

Hola Congreso de NodeJS, bienvenidos a mi charla sobre cómo llevar NodeJS a tu navegador con contenedores web. Hablaremos sobre la historia de Node, sobre los navegadores y finalmente sobre los contenedores web.

Los contenedores web son una tecnología de StackBits que te permite ejecutar aplicaciones de NodeJS dentro de tu navegador. Esta es realmente la primera vez que estamos hablando de esto en público, así que gracias por tenerme aquí.

Me llamo Silvia Vargas y soy una desarrolladora de front-end, pero también me encargo de las relaciones con los desarrolladores en StackBits.

Este es el plan para los próximos 20 minutos. Primero hablaremos sobre principios de los años 2000 y los intentos de sacar a JavaScript del navegador. Luego retrocederemos a los años 2020, donde hablaremos sobre cómo llevar Node.js al navegador. Y finalmente, echaremos un vistazo al presente y al futuro. Como verán, esta charla realmente comienza y termina con los navegadores, así que verán muchos de ellos en esta charla.

Si eres una persona a la que le gusta probar las cosas de inmediato, ve a echar un vistazo a node.neo, que es un entorno de pruebas de Node.js desechable impulsado por contenedores web. Mientras tanto, mientras experimentas el futuro, retrocederemos en el tiempo a principios de los años 2000. ¿Estás listo? Bien, entonces hablemos sobre la historia de Node.js.

Node.js fue creado por Ryan Dahl en 2009. Es importante tener en cuenta que JavaScript fue creado para ejecutarse dentro del navegador. En una de sus charlas, Ryan explicó cómo estaba buscando una forma de construir una aplicación de red que pudiera manejar una gran cantidad de solicitudes simultáneas. Antes de Node.js, hubo algunos intentos de ejecutar JavaScript fuera del navegador. Por ejemplo, uno de esos intentos fue Rhino. Pero nunca lograron llevar JavaScript del lado del servidor a la corriente principal. Node.js cambió eso. Veamos cómo sucedió.

En 2008, se lanzó Chrome con V8. V8 es un motor JavaScript. Es un proyecto de código abierto diseñado para ejecutar código JavaScript lo más rápido posible mediante la compilación JIT, just-in-time. Eso significa que JavaScript se compila a código de máquina y no se interpreta. Aquí está la publicación del blog de anuncio de 2008. No la leeremos en su totalidad, no te preocupes. Pero echemos un vistazo a un fragmento. Así que a nadie le gustan las citas largas, así que vamos a desglosarla. Aquí hay algunas palabras proféticas. A medida que las aplicaciones web crecen, creemos que este conjunto será representativo de cómo los desarrolladores web escriben código JavaScript. Chrome realmente cambió la forma en que se escribe JavaScript, pero también dónde se escribe. Y ahora la segunda parte de la cita. En la segunda parte, mencionan su conjunto de pruebas asombroso que consta de cinco aplicaciones JS promedio. Un total de 11,000 líneas de código, 11,000. Te dejo con este número. En este contexto, Ryan Dahl extrae el código fuente de V8 y pasa seis meses creando Node.js. Node.js fue diseñado para ser un marco del lado del servidor basado en eventos que pudiera manejar operaciones de E/S de manera no bloqueante. Ahora JavaScript realmente se puede ejecutar en todas partes. Y aquí hay una charla de 2009, JsConf, donde Ryan Dahl presentó esta idea.

Para comprender mejor nuestros problemas, los problemas a los que nos enfrentamos hoy, echemos un vistazo a la historia una vez más, o por última vez. ¿Cómo era Internet en esos días, a principios de los años 2000? En ese entonces, los navegadores no eran demasiado potentes. Por ejemplo, en una charla, Ryan Dahl menciona lo emocionado que estaba con la barra de progreso al cargar archivos.

Por ejemplo, en una charla, Rayon Daal menciona lo emocionado que estaba con la barra de progreso al cargar archivos. Solo para recordar, así es como se veía la barra de progreso. Quiero decir. Avancemos 15 años y vemos que los navegadores han crecido en potencia. Ahora, veamos la comparación. En los años 2000, 5 páginas promedio eran solo 11,000 líneas de código en total. Ahora, cuando ejecutas una aplicación de React Create, solo eso genera 30,000 líneas.

En 2005, se lanzaron Google Maps y Gmail. Ahora estamos hablando de computación en el borde, colaboración en tiempo real e IA. En ese entonces, los tres principales sitios web en 2005 eran Wikipedia, Flickr e iTunes. O en 2008. Ahora son Google, Facebook, TikTok. Si observas esos tres, en realidad, esas parejas son bastante similares, pero solo en términos de cómo se usan y no realmente la tecnología. Y en los años 2000, debemos recordar que eso fue antes de ES5, mientras que ahora estamos en muchas iteraciones de ECMAScript por delante. Tenemos los websockets, los service workers, y más. Dado lo poderosos que son los navegadores en la actualidad, tal vez realmente podríamos ejecutar JavaScript, incluido Node.js, en todas partes. Así que hablemos de cómo llevar Node.js a los navegadores.

El hecho de que puedas hacer algo no significa que debas hacerlo. Así que veamos qué se podría habilitar con Node.js ejecutándose en el navegador. Por ejemplo, hay un caso de uso en la educación. Desde cursos, blogs, hasta demos, tu audiencia podría experimentar lo que les estás enseñando directamente en el sitio web. Documentación, mostrar siempre es mejor que contar. Pruebas, crear reproducciones. Herramientas del lado del cliente, como empaquetadores, ejecutores de tareas, y generadores de código. Empleo, como plataformas de entrevistas o de incorporación. Y finalmente, experimentación. Nosotros mismos no sabemos cómo puedes aprovechar realmente los Contenedores Web al máximo. Ya veremos.

Así que ahora todo suena genial, pero, bueno, hay un pero. Node.js está diseñado para trabajar con API del lado del servidor, como sistemas de archivos, sockets de red y servidores HTTP.

Una gran parte de Node.js está escrita en C++, lo cual no se puede ejecutar en el navegador porque los navegadores solo hablan dos lenguajes, que son JavaScript y WASM. El entorno del navegador está diseñado para trabajar con APIs, lo que permite que el código de JavaScript interactúe con la interfaz de usuario, no sé, manejar eventos, y así sucesivamente.

Los navegadores también son entornos aislados. Están en un sandbox. Esto significa que no tienen forma de, quiero decir, no pueden acceder directamente a tu máquina local. Esto es por razones de seguridad. Entonces está claro que hay una incompatibilidad de API. Incluso si compilas Node.js a WASM, incluso si hablan los mismos lenguajes, eso aún no funcionaría porque no tienen las mismas herramientas.

Entonces existen algunos enfoques para resolver este problema de llevar Node.js a los navegadores. Uno de esos ejemplos serían máquinas virtuales en la nube, ejecutándolas para ejecutar código de usuario. Sin embargo, este enfoque tiene algunas desventajas. En primer lugar, es costoso. Tus usuarios pagan por minuto de conexión y también por almacenamiento. Y luego también está el costo ambiental. En segundo lugar, las máquinas virtuales dependen de la conexión a internet. Entonces, sin internet, no hay servicio. ¿Qué pasa si pierdes la conexión Wi-Fi mientras trabajas? Y en tercer lugar, también es peligroso. Este enfoque es popular entre los mineros de Bitcoin, pero también entre los sitios web de phishing, y así sucesivamente. Luego, otro ejemplo serían los playgrounds que no dependen de la nube, pero requieren parches personalizados para cada framework. StackViz tenía uno de esos playgrounds también con una tecnología llamada EngineBlock. Este enfoque no era escalable porque hay muchos frameworks diferentes por ahí. Sin embargo, el punto más importante es que simplemente no emula a Node.js. Solo emula sus capacidades muy limitadas. Como tener que proporcionar parches para cada framework individual.

Entonces, lo que estoy tratando de decir es que los parches, si los hay, deben mantenerse al mínimo para emular los comportamientos de Node.js con la mayor precisión posible. Entonces, ¿qué tal si te dijera que en realidad hay una mejor manera? Bueno, en mayo de 2021, Stackbrite anunció los contenedores web. Así como Randall extrajo el código fuente de V8 para permitir que JavaScript se ejecute fuera del navegador, Stackbrite extrae Node.js desde la fuente para permitir ejecutar aplicaciones de Node.js dentro del navegador. Entonces, Stackbrite emula el comportamiento de Node.js para ejecutarse en el navegador con WASM y con SAMREST con la mayor precisión posible. Aunque se anunció en mayo de 2021, los contenedores web ya funcionaban bien un poco antes. Por ejemplo, aquí hay un episodio de podcast donde Dom y Eric demuestran los contenedores web.

Entonces, ¿cómo logró Stackbrite hacer eso? Bueno, la historia se remonta a 2018, en realidad 2017, cuando Stackbits fue concebido. Antes de eso, Eric Simons y Albert Pai, eran dos amigos de la infancia. Estaban dirigiendo una plataforma donde se podía aprender a programar. Se dieron cuenta de que sus estudiantes generalmente tenían dificultades para configurar el entorno. Entonces, en 2018, pensaron que aprovecharían el poder de un navegador para reducir las barreras para aprender a programar. Los primeros dos años fueron muy frugales. Solo eran ellos y dos ingenieros, Dom Elm y Tomek Sulkovski. Entonces, Stackbits fue creciendo en equipo y también desarrollándose con containers. Aquí está, por ejemplo, nuestro equipo en este momento. Estamos en 14 países.

Entonces, hablemos de cómo, en realidad, descubrimos esta innovación. Esto implicó, por ejemplo, escribir todo el sistema de archivos, lo cual tomó tres iteraciones hasta que finalmente fue escalable y lo suficientemente rápido. Se trataba de implementar los módulos de ES, lo cual incluía, por ejemplo, importaciones circulares y cómo se instanciaban los módulos, implementar el bucle de eventos, implementar la API de serialización de V8, crear Turbo, que es nuestro propio gestor de paquetes, el cual actualmente estamos descontinuando porque ahora tenemos soporte nativo para gestores de paquetes, y luego también descubrir cómo ejecutar comandos de shell e integrar Git. Pero trabajar en contenedores web también significó diseñar para el futuro, un futuro que es sostenible, abierto y colectivo.

Desde el principio, StackBlitz se trató de apoyar todo el ecosistema web y tomar decisiones audaces sobre tecnologías emergentes. Por ejemplo, aunque la especificación de los hilos de Wasm solo ha alcanzado recientemente la fase tres en su camino hacia convertirse en un estándar, esta tecnología ha sido la base de los contenedores web desde hace mucho tiempo, permitiendo una velocidad increíble. Aquí también hay una publicación de blog si quieres leerla, escrita por mi colega, Roberto Vidal. En relación a eso, StackBlitz utiliza el búfer de matriz compartida, que es una característica moderna de JavaScript. Permite el procesamiento paralelo y tiempos de ejecución más rápidos. Elegirlo significaba un soporte inicial limitado para Safari, pero ya no. En enero de 2023, se anunció SafariTP con soporte para el búfer de matriz compartida y muchos de los frameworks funcionan en los contenedores web. Por ejemplo, aquí hay un proyecto de Astro, StealthKit y, por supuesto, Node. Ajustaremos los detalles antes de hacer un anuncio oficial. Pero construir para el futuro también implica un compromiso de mejorar todo el ecosistema. Aquí hay algunos ejemplos de cómo empujar los navegadores a sus límites benefició a la comunidad de desarrollo web. Por ejemplo, detectamos el reciente problema de memoria de V8 WASM, que era un límite estricto en el número de memorias WASM. Aquí está el problema y aquí hay una publicación de blog al respecto. También encontramos el error en los hilos de Firefox, aquí está el problema y aquí hay una publicación de blog al respecto. ¿Qué tal el problema de ARM en las MacBook M1? Aquí está el problema y acaba de ser solucionado. Como puedes ver, StackViz realmente empuja los navegadores a sus límites. Debido a eso, nos unimos a Bytecode Alliance, que es una asociación interindustrial que acelera la transición del mundo hacia la computación segura por defecto.

Pero mejorar todo el ecosistema no se trata solo de detectar errores. También somos grandes fanáticos del código abierto. En nuestro viaje, enviamos solicitudes de extracción a las herramientas que utilizamos. Por ejemplo, WASPAC, parking lot, PMPM, Git isomórfico. O como esta a Node.js, que allanó el camino para los paquetes universales. Pero también apoyamos a Wit no solo patrocinándolo o patrocinando Wit.conf, sino también contratando a su principal mantenedor que trabaja a tiempo completo en Wit. Todo esto es para decir que amamos el código abierto.

En mayo de 2022, trabajamos con el equipo de SvelteKit en la creación de la API de Web Container para que todos pudieran usar esta herramienta para empujar los límites de la web con nosotros. En febrero de 2023, la lanzamos y es gratuita para proyectos de código abierto así como proyectos con fines de lucro a pequeña escala. Si quieres aprender más sobre esto, puedes visitar webcontainers.io. Y allí, puedes ver en funcionamiento un pequeño contenedor web. También puedes probarlo tú mismo. Simplemente ve a webcontainers.new.

Veamos qué se ha construido hasta ahora con los contenedores web. Por ejemplo, en educación. Los contenedores web se utilizan en Total TypeScript, el increíble curso. Se utilizan en la documentación, por ejemplo, y en la demostración incrustada de la documentación de Node.js. Se utilizan como reproducciones de respaldo. Se utilizan en tutoriales, como el tutorial de Sveltekit. Se utilizan en experimentos, por ejemplo, esta aplicación de programación visual, Nano. Aquí también hay una aplicación que utiliza IA para generar otras aplicaciones. Y finalmente, también está la herramienta del lado del cliente. Por ejemplo, Cloudflare Wrangler que es una herramienta para desarrollar trabajadores de Cloudflare. Y tal vez este sea también un buen momento para hablar sobre cómo funcionan los contenedores web. Primero, el contenedor web inicia la aplicación. Esto sucede cuando se crea un iframe en el cual el contenedor web operará. Esto es otro nivel de seguridad. Como recordarás, el navegador es un entorno de sandbox. En el navegador, se ejecuta el contenedor web en su propio iframe para que no tenga acceso a ninguna información en la página de tu sitio web. Así que es un doble aislamiento.

Una vez que el contenedor web se inicia, entran en juego los trabajadores dedicados. Funcionarán como procesos para tu programa. Si estás instalando dependencias o si hay alguna situación con el administrador de paquetes, ya sabes, sucediendo, los containers web realizarán solicitudes para iniciar este dominio, que sirve como un proxy a los registros de paquetes gracias a los cuales la instalación está optimizada. Por lo general, de hecho, la instalación de dependencias es más rápida que en local. Si no es así, avísanos.

Y si tu aplicación cuenta con un servidor web, los containers web incluyen una pila de red TCP virtualizada que se monta en la API del service worker de tu navegador. Entonces, si tu aplicación Node.js ejecuta un servidor de desarrollo, se te pedirá que abras una URL que apunta a un dominio externo que en realidad está alimentado por un service worker localmente dentro de tu navegador. Debido a esta conexión, puedes abrir esta URL en otra pestaña y está aislada de forma segura de otra instancia del navegador. Eso también significa que incluso si pierdes la conexión a Internet a mitad de camino, aún puedes ver que esta URL funciona siempre y cuando el service worker esté registrado. Entonces, los containers web son realmente rápidos, más rápidos que en local debido a cómo manejamos las dependencias. Aquí tienes una demostración de PMPM, hasta cuatro veces más rápido que en local, y de Node.js. Nuevamente, si algo tarda más que en local, avísanos. Así que ahora, para resumir, ¿por qué usarías los containers web? Primero, es una forma segura de ejecutar código. Está aislado dos veces. Es una forma rápida de probar ideas. Es solo una URL y puedes programar. Y luego puedes compartirla con alguien. Es una forma económica. No tienes que pagar para ejecutarlo o usarlo. Tenemos planes de pago, por supuesto, pero la mayoría de nuestros usuarios disfrutan de Stack Vista de forma gratuita. Y antes de pasar a la última parte, echemos un vistazo al tweet que vi el otro día. Bueno, todos conocemos los problemas de guardar, clonar, cambiar a una rama, ejecutar dependencias, ejecutar el servidor de desarrollo. Quiero decir, mira la cantidad de likes. Hay tantas personas que se relacionan con esto. ¿Y si te dijera que esto ya no es un problema? Los containers web hacen que sea un placer revisar PR y verificar reproducciones. Aquí tienes, por ejemplo, un PR en Elkzone, que es un cliente de Mastodon muy bonito. En el PR, puedes ver un bot de la aplicación CodeFlow. Este botón proporciona un entorno instantáneo y desechable. CodeFlow IDE es una réplica de VS Code, pero alimentado por containers web, lo que significa que ejecuta Node.js dentro del navegador. Obtienes un entorno con solo un clic. Si haces clic en el botón de PR, verás todo el entorno con el servidor de desarrollo en ejecución y todas las extensiones recomendadas cargadas para ti. Si quieres probarlo, ve a cualquier repositorio de GitHub y simplemente agrega PR.new al principio. De esta manera, te unirás a dos millones de desarrolladores que utilizan los containers web mensualmente. Y eso es todo. Si tienes alguna pregunta, encuéntrame en Sylvia Vargas, o simplemente contáctame. Gracias por tenerme aquí.