El Futuro de los Runtimes de JavaScript

Hola a todos, mi nombre es Aron y quiero agradecerles por unirse a mí en Node-Congress. Hoy hablaré sobre el futuro de los runtimes de JavaScript. Vamos a ver cómo los runtimes de JavaScript han evolucionado desde los navegadores hasta los servidores y cómo Node y otras tecnologías han evolucionado en la última década y cómo eso dará forma a los runtimes del mañana, los que usaremos en 10 años. Creo que es un ejercicio interesante. Obviamente, ni yo ni otros podemos predecir realmente el futuro, pero lo interesante es que, como algunos de nosotros trabajamos en runtimes, tenemos la capacidad de influir en él. Así que creo que con esta charla, quiero abrir esa conversación, comenzar la conversación, y básicamente escuchar otros pensamientos porque creo que hay mucho espacio para innovar.

Y antes de comenzar, quiero hacer una pequeña aclaración. Obviamente, trabajo en Deno, así que tengo cierto sesgo. Me gusta Deno, obviamente. Pero diría que estos son principalmente mis puntos de vista personales. He estado trabajando a tiempo completo en runtimes de JavaScript durante menos de seis meses. Hay personas en mi equipo en Deno o incluso en NodeCongress hoy en día que tienen años o décadas de experiencia construyendo runtimes. Así que soy bastante nuevo en esto. Y también, por supuesto, mi charla no será exhaustiva. Principalmente me enfocaré en el lado de la CLI y la nube, obviamente los navegadores y el escritorio y el móvil son tendencias enormes y facetas importantes de JavaScript. Pero eso no será el enfoque de la charla de hoy. De todos modos, vamos a empezar. Así que, primero, echemos un vistazo a las tendencias históricas y cómo ha evolucionado JavaScript. Eso nos dará una idea de cómo podría evolucionar en la próxima década. Echemos un vistazo rápido a la línea de tiempo. JavaScript fue creado por Brendan Eich en 1995 en 10 días, lo cual es bastante extraordinario. Obviamente, hubo algunos compromisos. Y, ya saben, JavaScript siguió existiendo en los navegadores. Y fue solo hasta aproximadamente 2008 cuando Google lanzó V8 y Chrome, que las aplicaciones web realmente se convirtieron en algo, porque V8 cambió radicalmente el rendimiento de los runtimes de JavaScript y realmente permitió aplicaciones modernas y pesadas en JavaScript que antes no eran realmente posibles. Y luego, ya saben, menos de nueve meses después, Brian construyó y lanzó la primera versión de Node en 2009. Y eso, creo que eso es, ya saben, el impacto de Node no debe subestimarse. Obviamente, todos estamos aquí por Node. Node nos ha permitido construir aplicaciones del lado del servidor en JavaScript, y también ha permitido una gran cantidad de herramientas en el lado del front-end, etc. Así que creo que eso es bastante impactante. Obviamente, esta línea de tiempo no es exhaustiva. Hay otros eventos clave, pero una vez más, trato de centrarme en los puntos que considero relevantes. Y luego creo que, ya saben, otro evento clave en la línea de tiempo es cuando Microsoft lanzó TypeScript en octubre de 2012. Y lleva tiempo que la adopción de TypeScript crezca, pero hoy en día estamos empezando a ver que TypeScript es tal vez una de las formas o dialectos dominantes de JavaScript que los equipos utilizan para construir nuevas aplicaciones. Así que, mirando hacia atrás en 2010,

No quieren esperar por su linter. No quieren esperar por su formateador. Así que hay muchas cosas interesantes que están sucediendo allí. Y se ha producido la introducción de los complementos de Node que han evolucionado hacia una API, y hay un envoltorio llamado NAPI.RS, que te permite construir módulos de API en Rust. Y esto es utilizado por Prisma, Next.js, Rollup. Probablemente estemos viendo una especie de adopción de la tecnología Rust en las herramientas y en los runtimes, tanto en el lado de Node como en el de Deno. Y creo que eso continuará. Por lo tanto, esto no se refiere tanto a la implementación del runtime, sino más bien a la ergonomía y las API. Creo que seguiremos viendo la webificación. Cuando Node se lanzó por primera vez, no se alineaba realmente con las API web. Y creo que también las API web han madurado mucho en la última década. Por lo tanto, un hito importante es que Node 18 está enviando módulos ECMAScript, importaciones HTTPS y Fetch en Node 18. Y eso es un gran avance. Creo que a medida que estas API web han madurado, esencialmente se están convirtiendo en el estándar y podemos ir eliminando algunas de estas API heredadas más antiguas en favor de las API estándar, como por ejemplo, reemplazar el require crypto de Node por WebCrypto, o reemplazar HTTP y HTTPS por Fetch. Aunque, en la práctica, mucha gente ya utiliza Node Fetch. Mi experiencia personal es que las API integradas de HTTP en Node no son necesariamente las más agradables de usar, por lo que rara vez veo a la gente usarlas tal cual. De todos modos, pasando a otra cosa, creo que si nos alejamos de Node por un momento y miramos a Deno, Deno considera las API web como ciudadanos de primera clase. Intentamos implementarlas de la manera más completa posible. Intentamos cumplir con las especificaciones tanto como sea posible. Realmente creemos que hay mucho valor en implementar estas API web modernas. Hemos llevado esto bastante lejos. Ejecutamos tareas WPT, que son las mismas pruebas que ejecutan los navegadores. De hecho, en algunos casos, Deno es más compatible con las especificaciones que algunos de estos navegadores. Si echamos un vistazo a No Crypto, por ejemplo, Deno es más compatible con las especificaciones que Chrome y Firefox, solo ligeramente por detrás de Safari. Es interesante ver cómo una CLI en un runtime de servidor adopta estas API web modernas que han evolucionado y madurado en la última década. Volviendo a algunas de las tendencias, vimos que TypeScript fue una tendencia importante de la década de 2010. Creo que TypeScript se convertirá en el dialecto de facto que utilizan los equipos y los programadores. Es extremadamente extendido y tiene muchos beneficios. La organización TC39 está considerando la posibilidad de ignorar la escritura de tipos. Lo que esto permitiría esencialmente es que V8 y otros motores de JavaScript ejecuten TypeScript de manera predeterminada.

No entenderían los tipos, básicamente los ignorarían, pero podrían ejecutar TypeScript sin transformaciones, lo cual es realmente interesante. Creo que otra evolución es que JSX ha cambiado la forma en que construimos el frontend. Es esencial hoy en día. Y creo que dado que se ha convertido en un estándar de facto, posiblemente valga la pena considerar incorporar JSX al propio lenguaje. Eso puede ser bastante controvertido, pero tiene muchas ventajas de control. Y como mencioné anteriormente, TS Node tiene casi 20 millones de descargas semanales, lo que muestra una gran adopción. Obviamente, gran parte de eso probablemente sea CI, pero es justo decir que TypeScript ya no es el menospreciado hoy en día y admite TypeScript de forma nativa, porque creemos que merece un soporte de primera clase. Creo que otra evolución clave que veremos en los próximos años es que los runtimes. Node llevó a esta explosión y toda esta innovación con todas estas herramientas diferentes, y creo que eso era necesario y bastante importante, pero también conduce a mucha fragmentación en los flujos de trabajo diarios. Por lo tanto, creo que veremos una consolidación con estos runtimes todo incluido, y podemos ver eso aquí con Deno y Bun, por ejemplo, que incluyen vigilancia, linting, formateo incorporados. Creo que los runtimes tenderán a seguir en esta dirección. Obviamente, la implementación actual de Deno no es perfecta, pero seguiremos trabajando en ella y mejorándola. Creo que uno de mis últimos puntos es que Node es actualmente el runtime de JavaScript dominante. Deno es un poco el menospreciado. Está en alza y creciendo, y creo que estos dos runtimes convergerán. Cómo convergen aún está abierto e indefinido. Pero creo que vemos diferentes tendencias. Vimos que la webificación de estos runtimes está adoptando cada vez más las API web, lo que les brinda estas API compartidas en las que ambos pueden basarse. Deno tiene compatibilidad con Node y puede ejecutar aplicaciones complejas, como Express, Coa, herramientas frontend como Vite. Puede ejecutar administradores de paquetes como NPM y Yarn. La compatibilidad con Node aún no se ha lanzado oficialmente, y mi colega Bartek ha dado una charla al respecto, pero realmente está volviéndose muy potente. Y además, Native está evolucionando. Estamos evolucionando más allá de los complementos a Wasm y NAPI. Y Deno, ya sabes, estamos experimentando con el soporte de NAPI y Deno de forma nativa.

Entonces, creo que hay mucho espacio para que Node y Deno converjan. Creo que el principal impulsor es la fragmentación para los desarrolladores. No es divertido. No es genial. Así que, ya sabes, es una de esas cosas en las que esperaremos y veremos qué sucede, pero estoy emocionado al respecto.

Entonces, pasando de las CLIs, echemos un vistazo a las Nubes y los Runtimes en la Nube. Saben, creo que algunos de ustedes pueden estar familiarizados con IaaS o infraestructura como servicio, que es lo que AWS definió. Y creo que las Nubes en la última década han sido principalmente definidas por AWS, Azure, JCP y esas- la comercialización de primitivas como la computación y el almacenamiento. Y, saben, creo que en la próxima década veremos que la infraestructura como servicio se convertirá en aislamiento como servicio. Y profundizaré un poco en lo que creo que eso significa en unos pocos diapositivas. Si damos un paso atrás y miramos los hipervisores que se utilizan en la Nube, tradicionalmente tendríamos hipervisores de máquinas virtuales. Y las máquinas virtuales son- son extremadamente flexibles. Puedes ejecutar cualquier sistema operativo, pero son bastante caras. Tardan segundos en iniciarse, ¿verdad? Y en los últimos años hemos visto, por ejemplo, máquinas virtuales de firecracker, que también son técnicamente máquinas virtuales, pero son mucho más livianas. No intentan emular una máquina completa. Aún se basan en KVM y otras tecnologías clave. También hemos visto, obviamente, la aparición de tecnologías como, ya saben, LXCs y Docker, esencialmente contenedores, ¿verdad? Y el hipervisor dominante allí es Kubernetes. Y, ya saben, los contenedores son menos seguros que las máquinas virtuales, pero hay muchas mejoras en DX y en el rendimiento de inicio que los hacen atractivos. Y, ya saben, creo que la última evolución en estos hipervisores es- que estamos llegando ahora a estos hipervisores de aislamiento. Ya saben, en lugar de tener hipervisores que manejan máquinas virtuales, estamos obteniendo hipervisores que administrarán aislamientos, y estos son mucho, mucho, mucho más livianos. Se inician en un orden de magnitud más rápido que tanto los contenedores como las máquinas virtuales. Y hay muchas primitivas interesantes y cosas que podemos habilitar si adoptamos primero los aislamientos.

Entonces, ya saben, si damos un paso atrás y pensamos en una de las cosas, por ejemplo, que pueden- si pensamos en los hipervisores de aislamiento y en los ejecutables de aislamiento modernos, creo que hay esta idea interesante de puntos de entrada declarativos. Y, por ejemplo, hemos visto que Cloudflare ha lanzado esto, y esto es algo en lo que estamos pensando activamente en Deno con Deno Deploy. Ya saben, esto básicamente te permite declarar un programa de forma declarativa. Entonces, en lugar de tener esencialmente todas estas importaciones declarativas, tendrás- y luego tener un punto de entrada que sea imperativo, que extrae argumentos de argv o configura un oyente. Básicamente exportas funciones, y eso tiene muchos beneficios interesantes. Puedes exponer múltiples puntos de entrada en un archivo de JavaScript, por lo que un solo archivo de JavaScript ahora es autosuficiente para describir un programa completo. Y luego fomenta, ya saben, este enfoque de JavaScript primero, y es componible en todos los niveles a través de importaciones y exportaciones. Como, esto no tiene que ser un punto de entrada. Puedes volver a importar algunas de estas funciones y volver a envolverlas, por lo que puedes obtener esta agradable composición pura de JavaScript. Otra cosa que se habilita, ya saben, con estos hipervisores de aislamiento es que obtienes cosas como, por ejemplo, cuando construimos nubes tradicionales a menudo tenemos múltiples servicios llamados microservicios y tendremos que hablar con ellos, y eso a menudo sucederá a través de la red, ¿verdad? Será una llamada HTTP o una llamada TCP. Y creo que una de las cosas interesantes es cuando tienes el hipervisor de aislamiento que administra todos estos runtimes, en realidad puede, ya saben, en lugar de enviar estas llamadas a través de la red, puede enviarlas directamente a través de la memoria. Y así obtienes estas ganancias realmente interesantes en eficiencia y cosas que no son realmente posibles en estas abstracciones clásicas porque, ya saben, en la configuración clásica de VM o de contenedor todavía estamos trabajando con la pila IP como ciudadanos de primera clase. Mientras que aquí, ya saben, básicamente tienes un hipervisor gordo que comprende profundamente estos aislamientos y sabe cómo enrutar entre ellos. Entonces, sí, cuando pensamos en hipervisores de aislamiento, creo que el argumento principal es

Así que pasando del Cloud, y hay mucho más que decir, pero desafortunadamente solo tengo un poco de tiempo. Echemos un vistazo rápido a algunos de los casos de uso más exóticos en los que JavaScript podría incursionar o cómo podrían evolucionar los entornos de ejecución de JavaScript. Creo, ya sabes, que esto no es un tema nuevo, pero creo que se volverá a visitar. Vemos que JavaScript produce WASM o que JavaScript se compila de antemano. Así que vemos tanto assembly script como Microsoft static type script. Creo que también veremos los entornos de ejecución de JavaScript incrustados en más y más aplicaciones. Deno está diseñado para ser altamente incrustable. Hemos visto a personas tomar el entorno de ejecución de JavaScript rápido de Fabrice Billard y ejecutarlo en WASM. Así que tienes JavaScript en WASM, conectado a un entorno de ejecución de JavaScript, lo cual es bastante interesante. Y creo que en la próxima década, hay oportunidad para que JavaScript se incruste en más y más partes de nuestra infraestructura. Cloudflare introdujo JavaScript en la CDN, en esencia. Creo que la gente podría introducir JavaScript en bases de datos u otras partes clave de la infraestructura y hacer que sea scriptable.

Creo que uno de los cambios clave en, creo, la programación y el software en la última década es el aprendizaje automático. Ha tenido un impacto innegable en cómo construimos software y en los productos que consumimos. Y Deno, por ejemplo, tiene soporte de primera clase para Web GPU. Y si combinas eso con TensorFlow JS, básicamente tienes la posibilidad de tener entrenamiento e inferencia acelerados por GPU. Es compatible de forma nativa en un entorno de ejecución. Y obviamente eso es lo que Python hace mejor hoy en día, pero creo que sería interesante ver a JavaScript ganar terreno en ese aspecto.

Y aunque no es tan extremo como el aprendizaje automático, Python es el lenguaje de facto para la ciencia de datos. Y creo que hay espacio para JavaScript en ese campo. En Deno hemos experimentado con soporte de primera clase para Jupyter Notebooks. Y te permite escribir TypeScript en estos Notebooks y tener gráficos y todo eso integrado de manera coherente.

Sí, lamentablemente no tengo mucho tiempo, así que tendré que terminar. Pero podría haber pasado mucho más tiempo, creo, profundizando en el aspecto cloud y en estos hipervisores aislados y lo que permiten y el futuro de eso en Cloudflare y con DNO deploy. Pero para dejarles algunas preguntas finales, actualmente la web maneja alrededor de 150 millones de solicitudes por segundo, solicitudes HTTP por segundo. Y creo que es interesante preguntarse qué fracción de eso será procesada por algún entorno de ejecución de JavaScript, ya sea Node como origen upstream o si es el Edge de AWS Cloudfront, Lambda, Cloudflare Workers, DNO Deploy, creo que será interesante ver si en algún momento el 50% de todas las solicitudes HTTP pasan por JavaScript, ya sea para un enrutador de borde o su upstream. También me gustaría preguntarles, ¿creen que JavaScript está demasiado fragmentado? ¿Desean esta consolidación? ¿Desean esta consolidación en herramientas de formato y empaquetado? ¿Les gustaría ver a JavaScript expandirse más allá del desarrollo? ¿Cuáles son sus casos de uso? ¿Les gustaría usar JavaScript para microcontroladores, para el desarrollo de juegos? Sí, me encantaría escuchar sobre estos casos de uso. Y por último, creo que es importante considerar a TypeScript. ¿Se convertirá TypeScript en el lenguaje de facto utilizado para todo el desarrollo de JavaScript en el futuro? Creo que tiene buenas posibilidades. De todos modos, quiero agradecerles a todos por tomar el tiempo de ver mi charla y asistir hoy. Vamos a tener tiempo para preguntas y respuestas. Estoy muy emocionado por eso. Aquí es donde pueden encontrarme en línea. No duden en enviarme un correo electrónico o contactarme en Twitter si tienen alguna pregunta. Y con eso, terminamos. Muchas gracias, a todos. Ahora vamos a discutir las respuestas a sus preguntas de la encuesta. Veamos qué opinan las personas ¿Qué plataformas que se ejecutan en el borde has utilizado? El 40% ha utilizado Cloudflare Workers, luego el 25% Lambda Edge, y el 15% y 15% Versa y Dena Deploy, y el 5% Netlify Edge handlers. ¿Qué opinas de esto, Aaron? ¿Te sorprende o era lo que esperabas? Bueno, en cierto sentido, no me sorprende y refleja en gran medida mi comprensión, ¿verdad? Cloudflare realmente ha cambiado el juego y la percepción de estas plataformas modernas de ejecución de trabajadores. Han hecho un gran trabajo en eso. Creo que han hecho un trabajo fantástico.

Sabes, Lambda es AWS, que mucha gente utiliza de forma más o menos indirecta. Y luego, ya sabes, es interesante ver DEM deploy, que es el producto en el que trabajo. Tiene una cantidad decente de uso. Aún estamos en beta, obviamente, pero es bueno ver tracción allí. Así que, sí, quiero decir, estoy contento de ver esto. Y, sí, quiero decir, creo que hay mucho, ya sabes, podríamos incluso hablar sobre las diferencias entre estos entornos de ejecución de borde. Todos ejecutan JavaScript en última instancia, pero hay diferentes compensaciones en cada uno de esos entornos.

Gracias. Permíteme volver a... Así que, sí. Y ahora veamos algunas preguntas que la gente te ha hecho. La primera es por qué deberíamos usar isolate clouds, reemplazar contenedores y máquinas virtuales si son menos flexibles y solo pueden ejecutar JS. Sí, esa es una gran pregunta. Sí. La respuesta corta es que los contenedores y las máquinas virtuales seguirán existiendo durante mucho tiempo, ¿verdad? Pero creo que las isolate clouds reemplazarán gran parte del uso típico de contenedores y máquinas virtuales para JavaScript, porque son mucho, mucho más eficientes, ¿verdad? Hay grandes ganancias en eficiencia. Cloudflare ha hablado de algunas de ellas. Mencioné algunas de ellas en mi charla, ¿verdad? Donde tienes como costos cero de interconexión de servicios, mucho más eficiente en el uso de memoria, pueden ser mucho más eficientes en el cálculo. Y creo que lo más interesante es que estas isolate clouds pueden habilitar nuevas primitivas, cosas que antes simplemente no eran posibles, ¿verdad? Así que no se reemplazarán por completo. Pero creo que en esta década veremos un gran auge de personas que cambian de las máquinas virtuales y los contenedores clásicos a los aislados. Serán el mejor lugar para ejecutar JavaScript. Gracias. James, James pregunta, ¿hay planes conocidos o rumores de que AWS admita un entorno de ejecución oficial de Deno para Lambda? Sí, creo que esto se mencionó en la sala de Deno anteriormente. Actualmente hay un entorno de ejecución de Lambda de la comunidad para que las personas ejecuten Deno en Lambda. Creo que después de esta conferencia, investigaré si podemos hablar con AWS y tal vez crear una capa oficial de Lambda. Eso es definitivamente algo interesante. Creo que la compañía de Deno quiere que las personas usen Deno en todas partes donde puedan y quieran, ya sea en AWS, en Deno deploy, en Digital Ocean u otros proveedores. Así que definitivamente lo haremos.

Sí. Hablé sobre esta idea de las nubes de aislamiento. Realmente creo que hay mucho más que decir al respecto. Tal vez debería hacer de eso el enfoque de una charla, ¿verdad? Pero las primitivas de Unix, como el sistema de archivos de procesos y los sockets, han estado con nosotros durante mucho tiempo. Pero mencioné, por ejemplo, esta característica que Cloudflare tiene de comunicación entre servicios sin costo, en una configuración clásica, necesitarías hacer descubrimiento de servicios a través de DNS o algún tipo de servicio de consola. Y luego tendrías que averiguar qué IP está ejecutando este otro servicio y luego abrir un socket. Creo que estas nubes de aislamiento, porque están mucho más involucradas en cierto sentido con los aislamientos que se están ejecutando, proporcionarán muchas de estas primitivas de forma nativa. Y cuando estás construyendo aplicaciones que se ejecutan en todo el mundo, no tiene sentido programar para un proceso individual cuando estás construyendo algo que se ejecuta a nivel mundial. Así que creo que las primitivas de Unix han sido geniales. Nos han servido bien. Y tomará mucho tiempo que desaparezcan. Pero creo que a medida que comencemos a construir estas aplicaciones modernas de JavaScript para la nube, las veremos desaparecer y veremos emerger nuevas primitivas. Y tal vez cosas como el almacenamiento de blobs de primera clase o el almacenamiento KV, como Cloudflare lanzó el almacenamiento KV. Estábamos buscando lanzarlo en dealdeploy. Y creo que hoy una startup llamada temporal.io recaudó una Serie B de $100 millones, lo cual es bastante sustancial. Y una de las cosas que cambiaron es que cambiaron todo el mecanismo de tareas cron de encolado para reinventar esas primitivas, en parte porque están yendo más allá de las restricciones de Unix. Será un gran cambio porque a los desarrolladores les importa mucho Unix. Pero creo que necesitamos ir más allá para construir programas de una manera más moderna. Muy, muy interesante. AgentRL1990 pregunta, la computación se acerca cada vez más al cliente, ¿sientes que algún día pasaremos a una conexión con estado en el futuro lejano de la web? ¿Una conexión con estado? No estoy seguro exactamente a qué se refieren, una conexión con estado entre la nube y el cliente. Eso podría ser interesante, pero necesito entender un poco más los detalles de lo que quieren decir con conexión con estado. Oh sí, bueno, tal vez podamos hablar de eso en este tribunal con AgentRL1990, en un chat espacial. Sí, en un chat espacial podemos hablar de eso. Así que gracias, muchas gracias Aaron. Esta fue una gran charla y también grandes preguntas. ¡Así que sí! Muy bien, gracias a todos por asistir. Agradezco su tiempo. Sí, nos vemos a todos en el chat espacial. ¡Adiós!