El Supuesto ‘Fin’ de Node.js Es Mucho Ruido Sobre Nada

Hola, bienvenidos al Congreso de Node 2025. Este es el supuesto final de Node JS en mucho ruido sobre... nada. Comencemos.

Primero que todo, muy rápido. Estoy empleado por Platformatic, que ofrece la solución completa lista para usar para desplegar, optimizar, escalar automáticamente y asegurar todas tus aplicaciones de Node, sin ninguna reescritura y con ninguna complicación. Simplemente conectas y usas, como en los buenos viejos tiempos de USB. Échale un vistazo y contáctame por correo electrónico si estás interesado.

Está bien. Comencemos. No cuentes tus pollitos antes de que nazcan. Sabes, o podemos decir en Italia, no vendas la piel del oso antes de venderla, o antes de haberlo matado, lo que sea.

Y hay mucho que procesar hoy, así que hagámoslo. Primero que todo, déjame presentarme. Soy Paolo. Soy Ingeniero Principal en Platformatic y miembro del Comité de Dirección Técnica de Node T que vamos a ver en un momento de qué se trata. Vengo de una pequeña ciudad en el centro de Italia llamada Campobasso, que son bienvenidos a visitar si quieren venir a Italia.

Estos son todos mis colegas. Estos son todos mis contactos a los que puedes enviarme un mensaje. Así que mantente en contacto. Y también, tenemos que dar crédito. Esta charla fue originalmente hecha por Matteo Collina, mi amigo y CTO de Platformatic, lo que significa que cualquier cosa que salga mal hoy, es culpa de él, no mía. ¿Está bien?

Primero que todo, Node está muerto, ¿verdad? Veamos los números de cuán muerto está Node. Node tiene aproximadamente 3 mil millones de descargas por mes, lo que nos da un brillante número de 30 mil millones de descargas por año. ¿Crees que este es un proyecto muerto con 30 mil millones por año? No realmente.

Usualmente, vemos en internet esta cosa en todas partes. ZYX cambiará el runtime de JavaScript por defecto de Node.js. Este es el usuario aleatorio número uno. Y ahora hay, usualmente, que es algo que ves mucho más a menudo, XYZ destruirá Node.js, que es el usuario emocionado aleatorio número dos, que puede ser cualquiera. Así que, esta charla es sobre una pregunta que cualquiera está haciendo, todos están preguntando, y quiero dar una respuesta para esto hoy.

¿Está muerto Node? No. Punto. Adiós. Hemos terminado. Obviamente, no hemos terminado. Te voy a dar mucha información sobre esto. Pero Node no está, en ninguna parte, ni cerca de estar terminado, muerto, renovado, no descontinuado. Cualquier cosa que puedas pensar. No lo está. Y va a quedarse aquí por mucho, mucho tiempo.

Déjame también darte algunos ejemplos relacionados. Para cualquiera que diga que una tecnología está muerta, y alguien que diga que quiero apuntar a destruir algunas tecnologías por cualquier razón. ¿Puedes imaginar que COBOL, que nació en 1959, todavía se utiliza ampliamente, está en realidad en aumento, ocupando la posición 19 de popularidad? O que jQuery todavía se utiliza en aproximadamente el 95% de los sitios web habilitados para JavaScript, y que acaban de lanzarlo antes. No está, en ninguna parte, muerto, a pesar de React, Svelte, Solid, Vue, lo que sea que puedas pensar sobre. De todos modos, no estoy usando jQuery, pero jQuery no está, en ninguna parte, muerto.

Entonces, ¿qué pasa con Node? Bueno, Node es la tecnología más popular, según Stack Overflow. Y además, la combinación de Node y NPM no fue un error. Pudimos básicamente proporcionar una forma simple para que las personas resolvieran el uso de software. Tenemos una cantidad asombrosa de descargas en NPM cada mes, y eso también se debe a esta elección de combinar Node y NPM. Por ejemplo, estas son las descargas de ReadableStream, que es el cuarto módulo más descargado en NPM, que es básicamente un módulo que permite usar la API de Astreams de Node en el lugar de tu versión de Node y en el navegador. Así que, como puedes ver, la popularidad de Node y el uso están creciendo más del 50% al año, lo que significa que se está duplicando cada dos años, lo cual es mucho.

Además, la mitad de las descargas en Node son los archivos de encabezado. ¿Por qué es eso? Bueno, la cuestión es que los archivos de encabezado son necesarios cada vez que NPM necesita compilar algún complemento binario. En ese caso, necesitan descargar el binario, lo siento, los encabezados, y están almacenados en caché para este código. No solo lo descargas una vez, sino que esto significa que muchas personas o muchas nuevas máquinas se están implementando con Node por primera vez regularmente cada mes.

Además, hay muchas descargas divididas por plataforma, las tres principales plataformas, que son Windows, Mac y Linux. La mayoría de estas descargas probablemente provienen de la CI, porque también los proyectos a menudo prueban en Windows, lo sé porque en platformatic hacemos eso mucho, lo que significa que cada vez que tenemos que descargar Node, instalarlo en Windows y ejecutar nuestra suite de pruebas, que es algo que necesitamos hacer, especialmente si estamos en código abierto y apoyamos esta plataforma.

Pero de todos modos, esta es la idea. 30 millones de descargas en 2021, que se convirtieron en 60 millones de descargas en 2024. Así que se está duplicando, como te estaba diciendo. Además, un dato interesante sobre Node es que la versión 16, 14 y 12 siguen siendo masivamente populares. Aunque tienen muchas vulnerabilidades conocidas y, aún peor, en realidad están al final de su vida útil, así que no las uses. Si todavía estás en esta versión, intenta actualizar lo antes posible, por favor, porque es un riesgo masivo de vulnerabilidad. En otras palabras, si no estás actualizando Node.js regularmente, te estás poniendo en riesgo. Punto. Además, Node tiene un muy buen soporte a largo plazo. Una versión de Node te apoya durante aproximadamente 30 meses, la antigua versión par. Así que, se vuelven activas durante un año y luego se convierten en mantenimiento LTS por más de 18 meses, así que tienes mucho tiempo para actualizar.

Te damos mucho margen para actualizar, pero necesitas actualizar. No te olvides de eso. Además, ten en cuenta que la mayoría de los equipos actualizan su versión de Node cada dos lanzamientos LTS, lo cual no es ideal. Bueno, mejor que no actualizar en absoluto, pero aún así no es muy ideal. Así que, si puedes actualizarlo más rápido, por favor hazlo. Ahora, algunos números sobre las estadísticas organizacionales de Node. Así que, este es un período de un año que abarca desde noviembre de 2023 hasta noviembre de 2024. Así que, obtuvimos 20,000 nuevas estrellas.

Obtuvimos un asombroso número de 5,300 solicitudes de extracción, lo cual es mucho. 29,000 revisiones y 4,500 problemas, lo cual es mucho. Así que, nuestra relación de solicitudes de extracción a problemas está cerca de uno a uno, así que tratamos de no tener demasiados problemas nuevos, pero sigue siendo mucho. Es un proyecto muy, muy activo y vivo. Además, tenemos un número bastante estable de comentarios y envíos a Node Core, lo cual es bueno. Así que, la gente sigue participando en el proyecto. Y el número de solicitudes de extracción también es mayormente estable, lo cual es bueno, lo que significa que el proyecto no está yendo demasiado rápido y no está estancándose ni muriendo. Eso está bien. Tenemos nuestra tasa constante, pero somos capaces de mantenernos en contacto con todo lo que necesitamos. Y te mostraré sobre esto.

La esencia es que trabajamos muy duro para mantenerte a salvo. Así que, eres bienvenido. Tenemos muchas presentaciones de seguridad, que no siempre, por supuesto, se traducen en vulnerabilidades porque deben ser verificadas. Por supuesto, podrían estar duplicadas. No deben ser soportadas más. Hay varios casos, pero aún necesitamos intentar manejarlas. Pero de todos modos, tenemos un muy buen tiempo promedio de primera respuesta, que es en mediana, que es de aproximadamente un día y medio. Y también, un buen tiempo para triage, que sigue siendo de un par de días. Hemos mejorado en el último año, pero nuestro tiempo mediano está cerca de ser dos días y algo, lo cual es brillante, ¿verdad?

Además, Node.js fue uno de los primeros proyectos patrocinados por Alpha Omega, que fue iniciado por OpenSSF, que fue financiado por la mayoría de las grandes empresas que puedas imaginar, que son Microsoft, Google, Amazon, tú lo nombras. Básicamente, la misión es proteger a la sociedad catalizando mejoras sostenibles de seguridad para el proyecto. Básicamente, la idea es que quieren construir un mundo donde el código abierto crítico sea seguro y las vulnerabilidades sean encontradas, manejadas, arregladas y gestionadas de manera rápida y ágil. Porque la cosa es, la idea es que la mayor parte de la infraestructura de la que dependemos cada día para incluso algo no relacionado con la tecnología es ejecutada por el software de código abierto. Así que necesitamos ser muy responsables al respecto. Así que Node.js ha recibido aproximadamente $300,000 por año desde 2022 para trabajo de seguridad, lo cual es mucho, pero puedo decirte que es un dinero muy bien gastado.

Así que vamos a ponernos técnicos, porque a todos nos importa lo técnico y sé sobre ello. ¿Qué hemos enviado en los últimos años? Bueno, unas cuantas cosas. ESM. Ahora, la buena cuestión, que es el autor de esta cosa, no es muy aficionado a ESM, pero yo sí lo soy, y estoy realmente emocionado por esto. Todo lo que estoy haciendo ahora está finalmente soportado en ESM, y ahora puedes usar esta sintaxis compatible con el navegador en lugar de tener que depender de CommonJS y ESM en el otro lado.

Hay hilos. También tuvimos una charla muy interesante sobre cómo Node no ha sido de un solo hilo desde 2018, pero lo que sea. Ahora tenemos hilos estables y tienen mucha flexibilidad para hacer cosas de ciencia loca, confía en mí.

Luego tenemos fetch. Finalmente tuvimos fetch funcionando en Node. Ahora podemos usar la misma API en el navegador y en Node, así que no necesitas usar gotaxios, superrequest, lo que quieras usar. Solo usas fetch, que se basa en undici, que es un cliente impresionante para Node. Y tenemos muchas mejoras en la compatibilidad con la plataforma web. Tenemos fetch, tenemos flujos web, tenemos respuesta, criptografía web, de la estructura de datos clone, que es muy importante. Por favor, deja de hacer JSON stringify, JSON parse. Por favor. Ya no es necesario. Tenemos codificador y decodificador de texto, tenemos blob y archivo, incluso target, y el símbolo de dispose . Así que mucho. Y estamos trabajando para mejorar esto aún más, así que mantente atento a noticias emocionantes sobre esto.

Tenemos promesas desde siempre, pero ahora muchas de las API de Node ahora están prometidas por el diseño. No tienen que extenderlas. Por ejemplo, este es un ejemplo de cómo leer un archivo con promesas usando la API FS slash promises, que uso prácticamente todo el tiempo ahora. Tenemos el protocolo de Node para módulos, así que puedes distinguir fácilmente si estás incluyendo algo de Node o de un paquete de NPM, lo cual es muy agradable. Tenemos el watchmode. Watchmode es brillante, así que no tienes que usar concurrently o Node más, mientras son un proyecto encantador. No estoy en contra de ellos. Aún los uso para algunos casos de uso, pero ahora puedes tener todo en Node. Tienes la bandera de línea de comando watch y tienes la ruta de watch para personalizar qué rutas estás observando. Ahora, observan el archivo importado y reinician Node cuando cambian, como podrías esperar, por supuesto.

Y, por supuesto, funciona con el ejecutor de pruebas. Así que básicamente puedes tener un ejecutor de pruebas que se reinicia automáticamente muy rápidamente y muy fácilmente. Aún hay soporte limitado para plataformas. En este momento, solo es Mac OS y Windows, pero estamos trabajando en mejoras.

Tenemos el almacenamiento local asíncrono, que es una forma de rastrear tus llamadas de función asíncronas y tener algunos datos en contexto. Y, de hecho, lo estás usando todos los días si estás en Next.js, porque estos son los fundamentos para los componentes del servidor de React. Sin almacenamiento local asíncrono, no tendrías componentes del servidor de React.

Tenemos web crypto, que sigue siendo parte de la plataforma web. Así que, ahora, el Node crypto también es utilizable usando la API de la plataforma web, con un ejemplo como ese, donde puedes construir fácilmente HMAC de cualquier cosa, prácticamente. Y tenemos la función parse args para analizar tus argumentos de línea de comandos. Esto es bastante flexible y extensible, y ahora no tienes que usar paquetes adicionales si no quieres. Tienes todo integrado en Node, así que eso es mucho.

Finalmente, aplicación ejecutable única. Puedes inyectar Node en el, código en el binario de Node, que originalmente fue una idea de Postman Labs. Single command.js es el único formato admitido hasta ahora, y los binarios se pueden distribuir sin archivos adicionales. Así que, un solo archivo, como en el mundo de Go, si estás en el mundo de Go. Algunas otras herramientas que puedes probar, usar como postJect, pero no están siendo probadas activamente por los colaboradores de Node en este momento. Sistema de permisos, que es crucial para la seguridad. Así que, básicamente, hay algunas banderas que permiten restringir qué API son requeridas en tu, lo siento, permitidas en tu código, como FS, como child process worker, también tenemos net ahora.

Y básicamente, puedes restringir qué API puede ser ejecutada por tu script en el momento de ejecución. Y puedes verificar en tiempo de ejecución usando la API de permisos de proceso. Solía haber un proceso de permiso denegado para eliminar permisos en tiempo de ejecución, y ha sido temporalmente eliminado por algunos detalles de implementación que necesitan ser resueltos y podrían regresar en el futuro. Y finalmente, el ejecutor de pruebas. Es muy, muy flexible y admite subpruebas, omitiendo ganchos de ciclo de vida, admite simulaciones de funciones y temporizadores, y también la simulación de módulos está en camino, soporte de cobertura, y tiene buenos valores predeterminados de informes, que se predeterminan a spec o protocolo superior dependiendo si estás en un TTY, lo que significa que eres un terminal en vivo o un sistema automatizado. Uso el ejecutor de pruebas en todas partes y es brillante, simplemente es increíble. Así que, te animo encarecidamente a que le eches un vistazo.

Este es un ejemplo de un ejecutor de pruebas, una prueba escrita en el ejecutor de pruebas de Node. Como puedes ver, es bastante similar a lo que realmente estás acostumbrado. Así que, debería ser fácil migrar. Y también, tenemos WebSocket, y me encanta agradecerte, Matthew, por implementar el soporte de WebSocket en Node.

No fue fácil, pero ahora lo tenemos. Tenemos soporte en Node para WebSocket de forma nativa sin ningún módulo adicional. Ahora, aquí está la pregunta. Dadas todas las cosas emocionantes que te he estado mostrando, ¿sigues atrapado en 2015 o estás utilizando las nuevas, emocionantes y últimas características de Node? Así que, si necesitas aún más de esto, déjame mostrarte algo aún más emocionante.

Así que, estas son las dos cosas más emocionantes que saldrán en v22 y, por supuesto, 24. Primero que todo, require ESM y no hay necesidad de .mjs para la detección de sintaxis. Me gustaría agradecer enormemente a Joey y Geoffrey por este gran trabajo en esto. Como puedes ver ahora, puedes cargar un archivo ESM usando require, así que no necesitas hacer await import o otros trucos desagradables. Si el módulo ESM no tiene ningún await de nivel superior, simplemente funcionará. Punto. Y Node no necesita tener la extensión .mjs para detectar ESM porque ahora puede detectar qué sintaxis se está utilizando, lo cual es brillante. Es muy fácil interoperar los dos formatos ahora.

Otro por mi muy, muy buen amigo Marco. TypeScript. Bueno, ahora tenemos soporte automático de TypeScript. Marco ha hecho un trabajo increíble al escribir Amaro, que es el TypeStripper utilizado para esto. Te animo a que revises su charla nativa de TypeScript en línea. Puedes encontrarla en todas partes, que te da los detalles de eso. Pero la idea es que ahora, si miras en el lado izquierdo, puedes ver el archivo de TypeScript, que Node puede ejecutar sin ningún TSC, SWC, compilador, nada que pueda tomar. Simplemente lo ejecutas. Punto. Lo cual es brillante. Gracias, Marco, de nuevo.

Ahora Node no siempre es relajante porque es un proyecto masivo con muchas necesidades. Por eso te necesitamos. No soy el Tío Sam, pero la idea es bastante similar. Así que únete. Hablemos un poco sobre cómo funciona la gobernanza del proyecto. Primero que todo, Node es dirigido por la OpenJS Foundation, que nos brinda el apoyo legal y económico para operar toda la infraestructura. Y los colaboradores mantienen el repositorio de Node.js en GitHub.

Básicamente tienen acceso de commit al repositorio y pueden iniciar trabajos de CI. Cualquiera puede enviar un PR a Node, ya sea un colaborador o no colaborador. Usualmente las personas comienzan enviándonos no colaborador. Básicamente dependemos de las solicitudes de extracción de GitHub. Y el único colaborador, revisa y fusiona, lo que también nos referimos como Lend, solicitudes de extracción. Bastante fácil.

Nos basamos en un proceso de consenso. Así que, básicamente, la idea es que dos colaboradores deben aprobar un PR y luego puede Lend. Si un PR ha estado abierto por más de siete días, entonces una aprobación es suficiente. Después de ser aprobado, el colaborador debe, lo siento, la persona que envía el PR debe esperar 48 horas. Así que da más tiempo a las personas para hacer objeciones de último minuto antes de prestarlo. Aprobar un PR como colaborador significa que aceptas la responsabilidad por ese cambio. Así que si algo sale mal, eres responsable de solucionarlo. Y, por supuesto, si eres el autor de este cambio, no puedes aprobarte a ti mismo. Eso está concedido.

Ahora, si otro colaborador pide cambios, así que se opone a un cambio, entonces el cambio no puede Lend. En ese caso, es responsabilidad del TSC, del cual soy miembro, eventualmente anular y desestimar esta objeción mediante una moción o una votación. Pero usualmente eso no sucede. La mayor parte del tiempo, quiero decir, desde que he sido colaborador, que ha sido durante los últimos cinco años, no he visto ninguna anulación del TSC. Usualmente, los colaboradores, charlan entre ellos y son capaces de resolver el problema por sí mismos, simplemente buscando consenso.

Ahora, el Comité de Dirección Técnica de Node, que soy yo, Matteo y otras personas, obviamente. Así que son responsables del desarrollo técnico en Node, que es, establecemos la fecha de lanzamiento, el estándar de calidad, la dirección técnica, la gobernanza. La gestión en GitHub y todas las otras, básicamente, cosas organizativas. Somos responsables de mantener el COC, el código de conducta. Y también, somos responsables de mediar y colaborar con otros proyectos en la fundación. Eso es prácticamente todo. Eso es lo que hacemos. Y también somos responsables de resolver disputas entre otros miembros. Así que, básicamente, tomamos la decisión final entre otros miembros. Hay dos tipos de miembros del TSC, regulares y votantes.

Los regulares son básicamente miembros que pueden asistir a las discusiones del TSC, pero no votan. En cambio, los votantes, hacen todo. Son miembros regulares. Eso es un plus para votar.

Ahora, no hay límite de tiempo, ni límite de tamaño para el TSC. Y el TSC debe tener al menos cuatro miembros votantes en todo momento. Básicamente, la única forma de perder tu estatus de miembro votante, en su mayoría, es no votar. Si no votas varias veces en un año, básicamente cambias a ser un miembro regular. Eso es todo.

Además, esto es gigantesco, no más de 1/4 del TSC puede estar afiliado al mismo empleador. Lo que significa, que nadie puede controlar Node. Somos un proyecto totalmente dirigido por la comunidad. Punto. No es que seamos dirigidos por nadie. Microsoft, Google, Facebook, o lo que sea. Solo para nombrar. Pero somos dirigidos por nosotros mismos. Establecemos nuestra propia dirección. Eso es todo. Asombroso, ¿verdad?

Pero eso no fue lo más asombroso. Esto es lo más asombroso. Para que Node funcione con todas estas personas, todos tenemos que comprometer mucho. Incluso yo, como miembro del TSC, por ejemplo, tengo que comprometerme mucho cuando simplemente estoy enviando un PR. Eso es todo. Tenemos que comprometernos para lograr nuestros objetivos y hacer que las cosas funcionen. Listo. No hay otra manera. Así que si diriges algún proyecto de código abierto, ese es un consejo que te doy. La búsqueda de consenso es muy buena. Porque puedes mejorar mucho, tanto en el aspecto personal como en el aspecto técnico.

Y si sientes que quieres tener voz en el futuro de Node.js, hay un consejo simple que puedo darte. Comienza a contribuir. Solo estamos esperando por ti. Solo estamos esperando por ti. Necesitamos tu ayuda, energía, experiencia. Así que, comienza a contribuir. Puedes ser un coder, puedes ser un triager, puedes encargarte del sitio web, puedes ser un evangelista del proyecto. Necesitamos cualquier ayuda en cualquier cosa porque es un proyecto enorme. Todos son siempre bienvenidos.

Estamos esperando. Ahora, casi hemos terminado. Normalmente me encanta terminar mi presentación con una cita de personas mucho más inteligentes que yo. Y dado que comencé diciendo, no cuentes tus pollitos antes de que nazcan, te voy a dejar con una cita similar. De Jules Renard, que fue un muy buen escritor francés del siglo XIX, que dice que, No importa cuán viejo seas, sino cómo eres viejo. Sí, Node.js es un proyecto antiguo, tiene 16 años ahora, pero aún tiene promesas muy jóvenes y proyectos de vanguardia, a pesar de su edad. No estamos muertos todavía y no planeamos estar muertos pronto. Así que, por favor, deja de decir eso o deja de intentar provocarme cuando me encuentres en persona porque experimento eso mucho.

Sostendré tu provocación, pero esta es mi respuesta extensa y exhaustiva. Una vez más, bienvenidos por estar aquí para asistir a mi charla. Una vez más, gracias, Matteo, por reunir el material para esta charla y gracias a Node.Congress por hospedarme aquí hoy. Dicho esto, te agradezco mucho por tu atención y nos vemos pronto.