Node.js: lo Nuevo y lo Experimental

Hola a todos, mi nombre es Beth Brix y soy una ingeniera de software senior en Red Hat. Obtuve mi Red Hat hace solo cuatro meses cuando me mudé de IBM y estoy emocionada de estar aquí virtualmente en el Congreso de Node hoy. Hoy, mi charla se titula, Nuevas y experimentales características de Node.js. Como parte de mi rol en Red Hat, ayudé a mantener el tiempo de ejecución de Node.js. Soy miembro del Comité Técnico de Node.js. Soy particularmente activa en el Grupo de Trabajo de Lanzamiento de Node.js. Por lo tanto, a menudo dedico mi tiempo a determinar el contenido y producir los lanzamientos del tiempo de ejecución de Node. Y hoy quiero dedicar un tiempo a hablar sobre cómo las nuevas características llegan a manos de los usuarios de Node.js y por qué algunas características se lanzan como experimentales al principio. Hacia el final, mencionaré algunas de las características experimentales más recientes en las versiones más nuevas de Node.js. Node.js es un proyecto de impacto bajo la OpenJS Foundation. Anteriormente, estaba bajo la Fundación Node.js, pero cuando se fusionó con la JS Foundation, se convirtió en la OpenJS Foundation. Es posible que se sorprendan al saber que a pesar de estar bajo una fundación y tener un comité técnico de dirección, el proyecto Node.js no tiene una hoja de ruta formal. No hay un único patrocinador corporativo, es descentralizado y generalmente las características y cambios que se agregan al tiempo de ejecución son una suma de los intereses y requisitos de nuestros colaboradores. Normalmente, nuestros usuarios solo se enterarán de las nuevas características cuando se lanzan, ya sea a través de los registros de cambios o las publicaciones de anuncios de lanzamiento después de que se haya realizado el lanzamiento. Hay un flujo distintivo en el que puedes esperar que lleguen las nuevas características en los lanzamientos de Node.js. Node.js tiene un calendario de lanzamiento predecible. Tenemos dos lanzamientos principales al año, con números pares que se promocionan a soporte a largo plazo. Y dentro de ese calendario, tenemos tres fases de lanzamiento definidas. Actual, soporte a largo plazo activo y mantenimiento. Las líneas de lanzamiento con números impares no pasarán por las fases de soporte a largo plazo activo o mantenimiento, ya que no se promocionan a soporte a largo plazo, y es durante la fase actual donde la línea de lanzamiento recogerá la mayoría de los cambios no principales y no disruptivos que se incorporan a la rama principal del núcleo de Node.js. Durante la fase de soporte a largo plazo activo, solo se incorporarán nuevas características, correcciones de errores y actualizaciones que hayan sido auditadas por el equipo de soporte a largo plazo como apropiadas y estables para la línea de lanzamiento LTS. Y luego, en el mantenimiento, se restringirá solo a correcciones críticas de errores y actualizaciones de seguridad. Rara vez agregamos nuevas características a las líneas de lanzamiento de mantenimiento. A veces lo hacemos, pero eso es muy raro y solo en casos en los que agregar esa característica respalde a los usuarios que migran a versiones posteriores del lanzamiento. Por lo tanto, puedes esperar obtener las características más nuevas primero en la línea de lanzamiento actual, que en este momento es Node.js 15. Y típicamente, para una línea de lanzamiento actual, puedes esperar un lanzamiento cada dos semanas. Después de un tiempo, puedes esperar que las nuevas características se retroporten a las líneas de lanzamiento LTS. Pero no todas las características se retroportarán a LTS. Algunas se considerarán inestables para hacerlo, o tal vez el delta de código en las líneas de lanzamiento sea demasiado grande para poder traer esa característica de vuelta. Y si alguna vez tienes curiosidad sobre cuándo será el próximo lanzamiento, el grupo de trabajo de lanzamiento tiene problemas en su repositorio de GitHub que contienen horarios preliminares

Entonces eso es un poco sobre cómo las características se incluyen en las versiones. Pero ¿cómo sabes cuándo una característica es segura de usar en tus aplicaciones de producción? Bueno, Node.js proporciona un índice de estabilidad. A lo largo de la API, hay indicadores de estabilidad. Van desde la estabilidad 0, obsoleta, 1, experimental, hasta estable. Y generalmente aconsejamos a las personas que se adhieran a las características estables en sus aplicaciones de producción. Así que pasando por cada una de estas, las APIs obsoletas pueden ser obsoletas en la documentación o en tiempo de ejecución. Este es un ejemplo de obsolescencia en la documentación, y en particular, el tamaño del cubo de socket. Y puedes ver que incluye el ID de obsolescencia y la versión que introdujo la obsolescencia. Las obsolescencias solo en la documentación pueden aparecer en versiones menores. Entonces, no estarán restringidas a las principales, es posible que las veas. Y debido a que las obsolescencias solo en la documentación son solo eso, solo escritas en la documentación, puede ser difícil saber qué está obsoleto. Node.js proporciona una bandera de obsolescencia pendiente. Entonces, algunas obsolescencias solo en la documentación generarán una advertencia en tiempo de ejecución cuando se lance con esta bandera, por lo que si solo quieres ejecutar una verificación en tu script o aplicación, si alguna de las APIs que estás utilizando se va a obsoletar en una versión futura, puedes intentar ejecutarlo con esta bandera de proceso y debería decirte. En contraste, una obsolescencia en tiempo de ejecución generará, de forma predeterminada, una advertencia que se imprimirá en el error estándar la primera vez que se utilice la API obsoleta. Esta es la advertencia de protección de promesas no manejadas que puede resultar familiar, y debido a que esta advertencia es un cambio observable e impreso en el error estándar, generalmente solo verás que se introducen en las nuevas versiones principales, ya que agregar errores al error estándar podría romper las aplicaciones de las personas. Hay otros dos indicadores relacionados con el proceso, la bandera sin obsolescencia y la bandera de lanzamiento de obsolescencia. La bandera sin obsolescencia silencia las advertencias de obsolescencia, pero ten cuidado al usar esto porque es probable que estés silenciando un problema que deberás solucionar más adelante, ya que la API obsoleta eventualmente puede eliminarse. La bandera de lanzamiento de obsolescencia generará un error.

En cuanto a las características experimentales. El índice de estabilidad del proyecto Node.js establece que las APIs experimentales pueden cambiar de comportamiento. El contrato tradicional de Semver al que nos adherimos para las APIs estables no se aplica aquí, incluso en las líneas de versiones de soporte a largo plazo, y es por eso que decimos que se deben usar características experimentales con precaución en cargas de trabajo de producción, porque la superficie de la API puede cambiar. ¿Y por qué algunas características se marcan como experimentales y otras no? Bueno, en algunos casos, es posible que no se acuerde de antemano el diseño de API más adecuado y que queramos obtener un borrador temprano de la característica para que nuestros usuarios nos den comentarios y podamos evolucionar la API en consecuencia. Básicamente, en los casos en los que no queremos fijar la API demasiado pronto. Tenemos algunos módulos principales que todavía se designan como experimentales. Tenemos el módulo principal de Async Hooks que proporciona una API para rastrear recursos asíncronos, y esta semana hay discusiones en curso sobre marcar algunas de las APIs dentro de este módulo como estables. Tenemos el módulo principal de Diagnostics channel que proporciona una API para crear canales con nombre para informar datos de mensajes con fines de diagnóstico. Se pretende que un escritor de módulos que desee informar mensajes de diagnóstico utilice esta API para crear muchos canales para informar mensajes. También tenemos el módulo principal de inspector que todavía se marca como experimental. Este módulo proporciona una API para interactuar con el inspector de VA a través de Node y tenemos el módulo de eventos de traza. Y el módulo de eventos de traza proporciona un mecanismo para centralizar la información de traza generada por VA Node Core y

Y cabe destacar que no todas las características llegarán a salir de la fase experimental. Algunas han estado en estado experimental durante varios años y algunas pueden terminar siendo eliminadas por completo, sin haber salido nunca de la fase experimental. Esto es, nuevamente, parte de la razón por la cual sugerimos usar características experimentales con precaución, ya que es posible que nunca se vuelvan completamente estables. Y hay varias nuevas características estables en la última versión. Tenemos el controlador de aborto, tenemos MPM7, y V886. Y es a través de V8 que obtenemos las nuevas características del lenguaje JavaScript, por ejemplo, promise.any, aggregate error, string replace all y los operadores de asignación lógica, todos llegaron a través de V885. Y eso es lo que estamos lanzando en Node.js 15. Así que me gustaría animar a los usuarios de Node.js a echar un vistazo a nuestras características experimentales, probarlas y, con suerte, proporcionar comentarios sobre algunas de ellas. Cuantos más comentarios recibamos, más podremos evolucionar las APIs, dependiendo de esos comentarios o simplemente ganar confianza en que la estructura de la API es adecuada y luego promoverla a estable. Diría que tal vez no se apresuren a usar características experimentales en sus aplicaciones o implementaciones críticas por el momento, porque siempre existe el riesgo de que las cosas se rompan, se eliminen o se cambien. Pero sí, definitivamente echen un vistazo a algunas de nuestras características experimentales y nos encantaría escuchar sus comentarios. Y con eso, me gustaría desearles a todos un resto de conferencia agradable y espero unirme a todos ustedes en la sesión de preguntas y respuestas.

Vamos a ver los resultados de la encuesta de Bethany. Si recuerdas, Bethany nos preguntó qué versión de Node estás usando y yo agregué en producción y es la versión 14, bastante reciente. De memoria, no es la última versión LTS, ¿verdad? Es la última LTS, así que es genial ver a las personas usando la versión de producción. Es aquella en la que estás al tanto de las características, pero también obtienes estabilidad a largo plazo según la política de soporte.

Exactamente, exactamente. Entonces, Bethany, ¿estás satisfecha con estos resultados? Sí, es realmente bueno ver a Node 14 seguido de la 12, seguido de la 10 en esa fila, es exactamente lo que nos gusta ver. Porque muestra que las personas están migrando en un buen plazo, con la versión 10 de Node dejando de recibir soporte en abril. Es bueno ver que eso se está reduciendo, que las personas lo están usando. Otro u otras versiones más antiguas, es bueno verlo, creo que hubo respuestas a eso, así que es bueno ver que las personas no están usando versiones más antiguas que ya no tienen soporte. Así que ese 5% de personas que están usando Node 10, les quedan un mes y medio. Sí, dejen de hacer un plan para actualizar, y si tienen algún problema, tenemos un repositorio de ayuda donde pueden publicar sus problemas y estamos tratando de ayudar en la comunidad de Node. Sí, eso es algo bueno, especialmente en todo el desarrollo, por supuesto, siempre puedes encontrar personas dispuestas a ayudar. Eso es realmente agradable. Te ayudan en tu propio tiempo, y realmente me encanta eso de toda la comunidad de desarrollo en general. Al menos puedo hablar desde el mundo del front-end. No sé si es lo mismo en, digamos, las comunidades de Java, pero sí, me gusta eso sobre JavaScript al menos.

Entonces vamos a responder las preguntas de nuestra audiencia y vamos a entrar en ello. La primera pregunta que tengo es de ArthurZ91. ¿Podemos tener un poco más de detalles sobre los awaits de nivel superior? ¿Cómo debería funcionar, cuáles son los casos de uso y la API de Timers reemplazará a las bibliotecas CronJob? Gran pregunta. Bien, comenzando con los awaits de nivel superior, eso aún está en fase experimental y sigue la propuesta de awaits de nivel superior de EqnScript que pasó por TC39. Se trata de habilitar el uso del cargador de módulos para programar tu código asíncrono. En cuanto a los casos de uso, es cuando tiene sentido que tu módulo espere a que algo se cargue, y es entonces cuando lo usarías específicamente dentro de tu módulo. No se puede usar en CommonJS. Y hay algunas dificultades al usar awaits de nivel superior. Hay algunos buenos artículos al respecto. Intentaré pegarlos en el chat después. No puedo recordar de memoria todos los desafíos y dificultades, pero definitivamente te proporcionaré esa fuente, porque definitivamente vale la pena leerla, ya que hay casos de uso específicos en los que deberías hacer esto y en los que no deberías hacerlo. Genial. Y la última pregunta que había era, ¿la API de Timers reemplazará a las bibliotecas CronJob? Lo siento, déjame verificar la redacción de eso.