JavaScript nació en el navegador, Node lo llevó al servidor abrazando primitivas de Unix y E/S asíncrona, y recientemente Cloudflare Workers & Deno Deploy lo llevaron al borde. Veamos hacia dónde se dirigen los runtimes de JavaScript y cómo darán forma al software que escribimos.
Video Summary and Transcription
La charla de hoy explora el futuro de los runtimes de JavaScript, su evolución y su impacto en el desarrollo de software. Se discuten las tendencias históricas de JavaScript, la adopción de nuevas herramientas y bibliotecas, y la convergencia de Node y Deno. También se destaca la aparición de nubes aisladas y su potencial para reemplazar las máquinas virtuales y los contenedores tradicionales. Además, la charla aborda las posibilidades de JavaScript en casos de uso exóticos, su impacto en el aprendizaje automático y el potencial de TypeScript para convertirse en el lenguaje de facto para el desarrollo de JavaScript.
Available in English
1. Introducción a los Runtimes de JavaScript
Short description:
Hoy hablaré sobre el futuro de los runtimes de JavaScript, cómo han evolucionado y cómo darán forma a los runtimes del mañana. Es un ejercicio interesante explorar las posibilidades y abrir una conversación sobre la innovación y el progreso en 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.
2. JavaScript Runtimes: Tendencias y Evolución
Short description:
Hoy exploraremos cómo serán los runtimes de JavaScript en el futuro, sus nuevas capacidades, casos de uso, primitivas y ergonomía, y cómo impactarán en el desarrollo y despliegue de software. Daré mi punto de vista personal como alguien nuevo en el desarrollo de runtimes de JavaScript, con un enfoque en la CLI y la nube. También discutiremos las tendencias históricas de JavaScript, incluyendo la creación de JavaScript en 1995, la introducción de V8 y Chrome en 2008, y el impacto de Node en 2009. Otro evento significativo fue el lanzamiento de TypeScript en 2012, que ahora se utiliza ampliamente. Estas tendencias nos brindan información sobre la evolución de JavaScript en la próxima década.
y aún hay mucho espacio para que JavaScript progrese. Así que vamos a empezar. Creo que, como mencioné antes, veremos cómo serán los runtimes en 2025, 2030, qué nuevas capacidades tendrán, qué nuevos casos de uso permitirán, qué tipo de primitivas tendrán, qué tipo de ergonomía tendrán, cómo eso impactará en el software que construimos y escribimos o en cómo desplegamos software, cómo lo usamos. Creo que hay muchos ángulos diferentes que exploraremos a medida que avancemos en esto.
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,
3. JavaScript Front End and Runtimes Evolution
Short description:
Antes de 2010, el desarrollo front-end se basaba en bibliotecas como jQuery, pero ahora tenemos React, JSX, Vue y herramientas modernas como Babel, ES Build y Webpack. TypeScript y la arquitectura serverless también se han vuelto muy comunes. JavaScript ha experimentado cambios significativos, incluyendo la adopción de Yarn, promises, React, ECMAScript modules y fetch. Si bien el lenguaje central continúa evolucionando, esta charla se centrará en los runtimes de JavaScript y su evolución. JavaScript nació en el navegador y luego incorporó primitivas de Unix a través de Node. La pregunta ahora es si deberíamos introducir nuevas primitivas para la nube moderna.
Como saben, podemos ver algunas tendencias clave, como el desarrollo front-end. Obviamente, no quiero decir que el desarrollo front-end no existiera antes de 2010, pero realmente no era lo mismo. Antes de 2010, teníamos jQuery. Ahora tenemos React, JSX, Vue. Y obviamente, con estas bibliotecas modernas vinieron herramientas modernas, como Babel, ES Build, Webpack. Y eso también permitió frameworks modernos como Next.js o Tailwind CSS. Por lo tanto, el desarrollo front-end ha cambiado radicalmente en la década de 2010, especialmente en la segunda mitad de 2010. TypeScript obviamente también apareció. TS Node tiene alrededor de 18 millones de descargas por semana en npm, por lo que es muy común. Serverless se convirtió en algo. Para bien o para mal, ahora tenemos Lambda, Google Cloud Functions, Firebase. Pero creo que hay algunas diferencias entre el serverless y Lambda y las nubes modernas de las que hablaremos más adelante en la charla. Luego, obviamente, el desarrollo de aplicaciones de escritorio y móviles. Así que un breve resumen de algunas de las tecnologías que han cambiado. Surgió Yarn. Pasamos de los callbacks a las promises. Pasamos de jQuery a React. Pasamos de CommonJS con requires a ECMAScript modules e imports. Pasamos de XHR a fetch. Es difícil entender cuánto ha cambiado JavaScript en la última década.
Cuando pensamos en JavaScript, obviamente hay un lenguaje central. Y eso no será el enfoque de mi charla hoy. No me centraré en el lenguaje central, que sigue evolucionando constantemente. Hay muchas cosas interesantes que están por venir, como registros inmutables o tuplas, que son adiciones extremadamente interesantes a las que espero con ansias. Pero hoy me centraré más en un runtime de JavaScript. Por lo tanto, puedes pensar en ese lenguaje más primitivas específicas para un entorno. Y creo que cuando miras a JavaScript de manera integral, nació en el navegador, lo que le dio estas primitivas de cálculo y documentos centrales. Y luego, Node básicamente incorporó primitivas de Unix a JavaScript, exponiendo sockets Unix, sockets TCP, el modelo de procesos, la creación y bifurcación de procesos secundarios, todas esas cosas que lo hacen poderoso y útil para construir aplicaciones de línea de comandos y servidores. Pero creo que tiene sentido preguntarse, ¿qué sigue? ¿Vamos a seguir utilizando las mismas primitivas o vamos a crear nuevas? Y cuando pensamos en la nube moderna, ¿deberíamos incorporar primitivas de nube a JavaScript? Algo que vale la pena analizar. Así que sí, creo que la conclusión aquí es:
4. JavaScript Runtimes: Browsers and CLIs
Short description:
JavaScript ha evolucionado en los últimos 20 años y tenemos el poder de dar forma a su futuro. Los navegadores han experimentado mejoras notables, como la invención de contenedores web que permiten ejecutar aplicaciones completas similares a Node de manera eficiente en el navegador. Pasando a las interfaces de línea de comandos (CLIs), podemos esperar que se construya más tecnología central de ejecución de JavaScript en Rust, ofreciendo garantías de seguridad y una iteración más rápida. El aumento de Rust en herramientas, como Rome y SWC, está impulsado por la necesidad de velocidad en el desarrollo de aplicaciones front-end.
JavaScript está en constante evolución. Ha evolucionado en los últimos 20 años. Y lo interesante es que podemos dar forma a su futuro. Así que hagamos una primera parada en los navegadores. No me enfocaré demasiado en los navegadores, como mencioné antes, pero creo que hay algunas mejoras interesantes y bastante notables que nos afectan como usuarios de Node y Deno. Creo que algo bastante notable aquí es la invención de los contenedores web. StackBlitz lanzó esta cosa llamada contenedores web hace unos meses. Y te permite ejecutar aplicaciones completas similares a Node en el navegador. Lo hace de manera bastante eficiente. No es emulación. No quiero entrar demasiado en detalles, pero básicamente rellena las partes clave de Node y luego reimplementa una pila TCP utilizando service workers. Hay mucha tecnología interesante allí. Y creo que lo importante es que es básicamente Node empaquetado en el navegador. Pero sí, sigamos adelante porque los navegadores no son el enfoque de la charla de hoy.Entonces, echemos un vistazo a las interfaces de línea de comandos (CLIs) como Node, Deno, Bun y muchos otros. Y veamos cómo podrían evolucionar en la próxima década. Y una de mis primeras predicciones es la oxidación. Veremos cada vez más tecnología central de ejecución de JavaScript construida en Rust. Y la razón es que C++ es bueno, pero también es doloroso. V8 está construido en C++. Es probable que nunca se vuelva a escribir. Pero Rust es un lenguaje mucho más moderno que facilita la construcción de tecnología clave. Y ya estamos viendo esto. Deno está construido en Rust. Tiene envoltorios alrededor de V8 y Rust. Pero aparte de V8, casi todo Deno es Rust. Y eso proporciona algunas garantías de seguridad, pero también creo que aumenta la velocidad de iteración en el tiempo de ejecución, lo que lo hace mucho más accesible para que las personas contribuyan. También estamos viendo el aumento de Rust en herramientas como Rome o SWC. Estas son participaciones bastante interesantes y están motivadas principalmente por la velocidad. La gente no quiere esperar a que se construyan sus aplicaciones front-end.
5. Evolución de los Runtimes de JavaScript y las API web
Short description:
No quieren esperar por su linter. No quieren esperar por su formateador. La introducción de los complementos de Node ha evolucionado hacia una API, y hay un envoltorio llamado NAPI.RS, que te permite construir módulos de API en Rust. Node 18 está enviando módulos ECMAScript, importaciones HTTPS y Fetch. Deno considera las API web como ciudadanos de primera clase y tiene como objetivo cumplir con las especificaciones. Deno es más compatible con las especificaciones que algunos navegadores. TypeScript se convertirá en el dialecto de facto. La organización TC39 está considerando la posibilidad de ignorar la escritura de tipos para ejecutar TypeScript de manera predeterminada.
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.
6. JavaScript Runtimes: Evolution and Convergence
Short description:
No entenderían los tipos, básicamente los ignorarían, pero podrían ejecutar TypeScript sin transformaciones, lo cual es realmente interesante. Otra evolución es que JSX ha cambiado la forma en que construimos el frontend. Es esencial hoy en día. TypeScript ya no es el menospreciado y admite TypeScript de forma nativa. Los runtimes tenderán hacia la consolidación con un runtime todo incluido. Node y Deno convergerán, adoptando cada vez más las API web. Deno tiene compatibilidad con Node y está evolucionando más allá de los complementos a Wasm y NAPI. Hay espacio para que Node y Deno converjan, impulsados por la fragmentación para los desarrolladores. Pasemos a las Nubes y los Runtimes en la Nube.
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.
7. Clouds and Isolate Hypervisors
Short description:
En la próxima década, la infraestructura como servicio se convertirá en aislamiento como servicio. Los hipervisores están evolucionando de la gestión de máquinas virtuales a la gestión de aislamientos, que se inician más rápido y permiten primitivas interesantes. Los puntos de entrada declarativos, como los utilizados por Cloudflare y Deno Deploy, permiten programas de JavaScript autosuficientes y composición. Los hipervisores de aislamiento pueden enrutar llamadas directamente a través de la memoria, lo que resulta en ganancias de eficiencia.
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
8. Isolate Clouds and the Future of Cloud Workers
Short description:
Cuando se ejecutan programas multiinquilino, las VM y los contenedores no son viables debido a su sobrecarga. Los aislamientos proporcionan una solución de bajo costo para la multiinquilinidad. Las nubes de aislamiento modernas adoptarán los aislamientos como su primitiva de cómputo, con servicios de aislamiento enrutables directamente. Están surgiendo almacenes de blobs y KV para reemplazar los dispositivos de bloques. Los hipervisores aislados, como en Cloudflare Workers y Deno Deploy, pueden llevar a la aparición de una especificación de Cloud Workers.
hay ganancias extremas de eficiencia. Cuando intentas ejecutar, ya sabes, cientos, miles o decenas de miles de programas multiinquilino en la misma máquina, eso no es realmente posible o viable con las VM. Tampoco es posible con los contenedores. Solo los aislamientos tienen una sobrecarga lo suficientemente baja como para permitir una especie de multiinquilinidad. Y, ya sabes, también creo que cuando miramos hacia atrás en la nube de la última década, esencialmente, preserva algunas de las abstracciones clave con las que hemos estado trabajando que nos han servido bien, pero que tal vez estén un poco desactualizadas, ¿verdad? Y creo que estas nubes de aislamiento modernas adoptarán los aislamientos en lugar de las VM como su primitiva de cómputo. En lugar de tener, ya sabes, IPs internas y VPC y redes privadas y NUTS que se replican, ya sabes, infraestructura tradicional, tienes servicios de aislamiento enrutables directamente donde no te importa dónde se esté ejecutando el otro servicio. Podría estar ejecutándose en otro lugar del mundo, podría estar ejecutándose en la misma máquina hipervisor, se enruta. Y luego, ya sabes, está surgiendo el almacenamiento de blobs y KV para reemplazar los dispositivos de bloques. Y hay oportunidad para que estos hipervisores sean nativos, como estamos viendo en Cloudflare Workers o Deno Deploy. Y entonces, ya sabes, con estos hipervisores aislados, que son esencialmente la implementación del tiempo de ejecución, creo que veremos la aparición de una especificación de Cloud Workers, ¿verdad? Los service workers fueron un buen punto de partida, pero AddEventListener Fetch está desactualizado, no es el futuro. Cloudflare todavía lo admite, Deno Deploy todavía lo admite, pero sabemos que necesitamos ir más allá de eso. Y, ya sabes, creo que lo clave aquí es que en estas Nubes, ya no solo estamos empaquetando node y contenedores. Son verdaderamente nuevas primitivas y, ya sabes, un nuevo modelo de proceso, y eso potencialmente justifica una nueva especificación.
9. JavaScript en casos de uso exóticos
Short description:
JavaScript podría incursionar en casos de uso exóticos y evolucionar en entornos de ejecución. Puede producir WASM y ser compilado de antemano. Los entornos de ejecución de JavaScript se pueden incrustar en aplicaciones. Deno es altamente incrustable. JavaScript se puede incrustar en la infraestructura. Cloudflare introdujo JavaScript en la CDN. JavaScript podría ser introducido en bases de datos y otras partes clave de la infraestructura para hacerlas scriptables.
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.
QnA
JavaScript's Impact on Software and Future Trends
Short description:
Uno de los cambios clave en 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. JavaScript tiene el potencial de ganar terreno en el aprendizaje automático y la ciencia de datos. TypeScript podría convertirse en el lenguaje de facto para todo el desarrollo de JavaScript. Gracias por asistir a la charla. Ahora discutamos los resultados de la encuesta y el uso de las plataformas de borde.
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.
Lambda, Isolate Clouds, and Deno Runtime
Short description:
Lambda es AWS, que muchas personas utilizan indirectamente. DEM deploy, el producto en el que trabajo, tiene buena aceptación. Hay diferencias entre los entornos de ejecución de borde, pero todos ejecutan JavaScript con diferentes compensaciones. Las isolate clouds reemplazarán el uso típico de contenedores y máquinas virtuales para JavaScript debido a las ganancias de eficiencia y la habilitación de nuevas primitivas. Aunque no se reemplazarán por completo, habrá un auge en las personas que cambien a los aislados. Actualmente, hay un entorno de ejecución de Lambda de la comunidad para Deno en AWS, y en el futuro podríamos explorar una capa oficial de Lambda.
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.
Convergence of Deno and Node
Short description:
Deno y Node podrían no poder coexistir para siempre en el límite. O bien se fusionarán o uno reemplazará al otro. Una biblioteca estándar de JavaScript que comparta conocimientos previos es una gran idea. Primero convergerán antes de posiblemente reemplazarse mutuamente.
investigar eso. Gracias. Eso suena prometedor. Como, sí. James ha hablado ahora sobre una biblioteca estándar de JS, ¿es así como crees que Deno y Node convergerán, o esperas que un runtime reemplace al otro en el límite? Sí. Esa es una gran pregunta y difícil. Creo que la fragmentación es dolorosa. Entonces, Deno y Node podrían no poder coexistir para siempre en el límite. Creo que dentro de cinco o diez años, o bien se fusionarán de alguna forma o uno reemplazará al otro. Pero creo que, como dijo James, en la última década hemos visto mucha expansión e innovación en JavaScript. Y creo que estamos pasando de una fase de expansión a una fase de consolidación. Y creo que una biblioteca estándar de JavaScript que comparta conocimientos previos en el tiempo es una gran idea. Así que creo que primero convergerán allí antes de posiblemente reemplazarse
Unix Primitives and the Future of Isolate Clouds
Short description:
Las primitivas de Unix pueden volverse obsoletas en las nubes de aislamiento modernas, ya que estas nubes proporcionan muchas de estas primitivas de forma nativa. La construcción de aplicaciones a nivel mundial requiere ir más allá de la programación para procesos individuales y adoptar nuevas primitivas como el almacenamiento de blobs de primera clase y el almacenamiento KV. La reinvención de los mecanismos de tareas cron de encolado por parte de startups como temporal.io indica un alejamiento de las restricciones de Unix. El futuro podría implicar una conexión con estado entre la nube y el cliente, aunque se necesita una mayor clarificación. ¡Gracias por asistir a la charla y nos vemos en el chat espacial!
el uno al otro, quiero decir, uno u otro. Sí. Sí, gracias. Entonces dijiste que las primitivas de Unix podrían volverse obsoletas en las nubes de aislamiento modernas. ¿Podrías explicarlo, por favor?
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!
