Video Summary and Transcription
Beth Brix, una ingeniera de software senior en Red Hat, habla sobre las características nuevas y experimentales en Node.js, el proceso de lanzamiento, la estabilidad de la API y la importancia de los comentarios de los usuarios. Algunas características estables en Node.js 15 incluyen el controlador de aborto, MPM7 y V886. La versión más popular entre los usuarios es Node 14. Las futuras versiones de Node.js probablemente incluirán una importante actualización de v8 con nuevas características del lenguaje JavaScript. La comunidad de Node es solidaria y está dispuesta a ayudar a los usuarios con la migración y la búsqueda de soluciones.
1. Introducción a las características de Node.js
Hola a todos, mi nombre es Beth Brix, una ingeniera de software senior en Red Hat. Hoy, mi charla se titula Nuevas y experimentales características de Node.js. Discutiré cómo las nuevas características llegan a manos de los usuarios de Node.js y por qué algunas características son experimentales al principio. Node.js tiene un calendario de lanzamiento predecible, con dos lanzamientos principales al año y tres fases de lanzamiento definidas. Las características más nuevas están disponibles en la línea de lanzamiento actual, actualmente Node.js 15. Con el tiempo, las nuevas características se retroportan a las líneas de lanzamiento LTS. El grupo de trabajo de lanzamiento proporciona horarios preliminares por lanzamiento.
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
2. Proceso de lanzamiento de Node.js y mantenerse informado
A veces, los horarios de lanzamiento pueden cambiar debido a lanzamientos de seguridad. Node.js no tiene una hoja de ruta oficial, pero existen esfuerzos a largo plazo, como grupos de trabajo e iniciativas estratégicas, dedicados a áreas específicas del proyecto. Por ejemplo, el esfuerzo de los módulos se centró en la implementación de los módulos de ECMAScript. Puedes seguir estos esfuerzos en GitHub y Twitter para mantenerte actualizado.
por lanzamiento. Estos están sujetos a cambios según el lanzamiento o la disponibilidad. A veces tenemos para acomodar lanzamientos de seguridad desde casa, lo que puede retrasar un poco los horarios, y en general, no programaremos lanzamientos de mantenimiento a menos que haya correcciones de errores críticas que deban realizarse. Tanto el cronograma en la diapositiva anterior como estos problemas se pueden encontrar en GitHub.com barra Node.js barra lanzamiento. Pero, ¿cómo puedes saber qué está en proceso? A pesar de no tener una hoja de ruta, existen esfuerzos a largo plazo que puedes seguir para tener una indicación de lo que viene a continuación. Tenemos grupos de trabajo, equipos e iniciativas estratégicas dedicadas a áreas específicas del proyecto. Y estos grupos actúan como fuerzas de tarea para impulsar ciertos temas. Por ejemplo, en el pasado, tuvimos el esfuerzo de los módulos centrado en la implementación de los módulos de ECMAScript. Puedes seguir el repositorio en GitHub, pero es posible que te sientas abrumado por las notificaciones allí. Es difícil mantenerse al día. Y el proyecto también ha iniciado recientemente los esfuerzos de los próximos 10 años, que se centra en definir nuestros valores y deseos para guiar la dirección de el proyecto en los próximos 10 años. También puedes intentar seguir a algunos de los colaboradores activos en Twitter, muchos están en esta conferencia. Así que esa es otra buena manera de mantenerse actualizado.
3. Node.js API Stability and Experimental Features
Node.js proporciona un índice de estabilidad con indicadores de estabilidad para sus APIs. Las APIs obsoletas pueden ser documentación o estar obsoletas en tiempo de ejecución. Node.js ofrece una bandera de obsolescencia pendiente para obsolescencias solo en la documentación y una advertencia en tiempo de ejecución para obsolescencias en tiempo de ejecución. Las características experimentales en Node.js pueden cambiar de comportamiento y la superficie de la API también puede cambiar. Algunas características se marcan como experimentales para recopilar comentarios de los usuarios y evolucionar la API en consecuencia. Los módulos principales como Async Hooks, Diagnostics channel, inspector y trace events todavía se marcan como experimentales.
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
4. Node.js Experimental Features
El módulo principal de la interfaz del sistema WebAssembly proporciona una implementación de la especificación de la interfaz del sistema WebAssembly. Las APIs experimentales incluyen Lotus, TopLevelAwait, módulos JSON, módulos WASM, políticas, soporte de mapas de origen, API de promesas de temporizadores y API de criptografía web. Algunas características experimentales requieren banderas de proceso, mientras que otras requieren compilar Node.js desde el origen. Las características estables siguen la versión semántica y tienen como objetivo mantener la compatibilidad del contrato de la API. Las características se promocionan a estables cuando los colaboradores tienen confianza en la API y los comentarios ayudan a obtener consenso.
Incluso tu propio código de aplicación. Y finalmente tenemos el módulo principal de la interfaz del sistema WebAssembly, que también es experimental y proporciona una implementación de la especificación de la interfaz del sistema WebAssembly. Y tenemos algunas APIs experimentales específicas. Por ejemplo, muchas de las APIs de módulos ECMAScript ahora están marcadas como estables, pero algunas de ellas no lo están. Las que aún son experimentales incluyen la API Lotus, que se utiliza para personalizar el algoritmo de resolución de módulos predeterminado. TopLevelAwait, que te permite usar un await fuera de una función asíncrona dentro de un módulo ECMAScript, y los módulos JSON y WASM para admitir la carga de estos. Las políticas son otra API experimental. ¿Qué son las políticas? Node.js contiene soporte experimental para crear políticas en la carga de código, y esto está inspirado en el mecanismo de seguridad del navegador para hacer cumplir la integridad de los recursos. Otra API experimental es el soporte de mapas de origen. Los mapas de origen proporcionan un método para traducir desde el origen generado hasta el original. Y esto tiene como objetivo aliviar algunos de los desafíos de observabilidad al usar las variantes alternativas de JavaScript. También está la API de promesas de temporizadores. Esto se agregó en Node.js 15 y proporciona una interfaz de promesa para los temporizadores en lugar de usar el método tradicional de devolución. Y luego está la API de criptografía web, que expone una implementación de la API estándar de criptografía web. Y deberías ver la charla de James Snell en esta conferencia sobre eso para obtener más información. Y muchas de estas características experimentales están ocultas detrás de banderas de proceso. Y esto es para hacerlas opcionales. Entonces, para comenzar a usar algunas de estas, deberás iniciar tu proceso con una de estas banderas. Por ejemplo, para comenzar con una característica de política, debes pasar la bandera de experimento de política. Y luego tenemos algunas características muy experimentales que están ocultas detrás de banderas de tiempo de compilación. Para usar estas, en realidad debes compilar Node.js tú mismo desde el origen. ¿Por qué hacemos esto? Bueno, principalmente para poder trabajar en la creación de implementaciones muy tempranas de una característica y construirlas y probarlas en nuestro entorno de integración continua sin que se publiquen. Si alguien desea usar alguna de estas características, como mencioné, deberá compilar Node.js usted mismo desde el origen, y la información sobre cómo hacerlo se puede encontrar en el archivo de construcción MD en el repositorio de tiempo de ejecución de Node.js. Finalmente, tenemos características estables. Para las características estables, se aplica la versión semántica. Con estas características, puedes tener la confianza de que intentaremos mantener el contrato de la API. Solo experimentarás cambios de API disruptivos en características estables en la próxima versión principal. La compatibilidad es una prioridad, pero hay una excepción. Si un problema de seguridad requiere que realicemos un cambio de API disruptivo, podemos implementarlo como parte de una versión menor, pero esto solo se hace cuando es absolutamente necesario. Entonces, ¿cómo y cuándo se promocionan las características a estables? Es cuando los colaboradores más involucrados en la característica tienen confianza en la API y no creen que sean necesarios más cambios. ¿Cómo podemos llegar más rápido? Cuantos más comentarios recibamos sobre una característica experimental, más rápido podremos obtener confianza y consenso en la estructura de la API.
5. Características Experimentales y Últimas Versiones Estables
No todas las características saldrán de la fase experimental. Algunas pueden ser eliminadas por completo. Node.js 15 tiene nuevas características estables como el controlador de aborto, MPM7 y V886. Las características del lenguaje JavaScript como promise.any, aggregate error, string replace all y los operadores de asignación lógica están disponibles a través de V8. Se anima a los usuarios de Node.js a probar las características experimentales y proporcionar comentarios. Sin embargo, se recomienda precaución al usar características experimentales en aplicaciones críticas. Disfruten de la conferencia y nos vemos en la sesión de preguntas y respuestas.
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.
Resultados de la Encuesta de Node.js y Preguntas y Respuestas sobre Awaits de Nivel Superior
Vamos a ver los resultados de la encuesta de Bethany sobre el uso de Node.js. La versión más popular es la 14, seguida de la 12 y la 10. Es genial ver a las personas migrando dentro de un buen plazo, ya que la versión 10 de Node dejará de recibir soporte en abril. Alentamos a los usuarios a actualizar y buscar ayuda en la comunidad de Node. Ahora, abordemos una pregunta sobre los awaits de nivel superior y la posible sustitución de las bibliotecas CronJob por la API de Timers.
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.
Características de Node.js y Futuras Versiones
No creo que las bibliotecas CronJob sean reemplazadas. Las características de mapas de origen habilitados y recursos asíncronos y almacenamiento local se dirigen hacia la estabilidad. La función de informe de diagnóstico, originalmente un módulo externo, se fusionó en el núcleo de Node para aumentar la adopción. Tiene el potencial de reemplazar herramientas como New Relic. Node 16, la próxima versión principal, probablemente incluirá una importante actualización de v8 con nuevas características del lenguaje JavaScript.
Bibliotecas CronJob. No creo que sea así. Creo que las bibliotecas CronJob seguirán existiendo. Como con todas las nuevas características, lleva mucho tiempo cuando hay cosas probadas y confiables en la comunidad a las que la gente se aferra, lleva mucho tiempo para que la gente se aleje de eso y simplemente use la implementación de bajo nivel. Tiene que haber un beneficio para hacerlo, y no lo sé. La gente no se mudará automáticamente y comenzará a usarlo. No. Puede hacerlo, pero las bibliotecas CronJob también son muy útiles. Tengo otra pregunta, que es, ¿qué característica experimental crees que se volverá estable en Node.js Next? Una de ellas, los mapas de origen habilitados que mencioné en la charla sobre proporcionar un método para traducir el origen generado de vuelta al original. Eso se inició alrededor de la versión 12 de Node, y en realidad ya recientemente, esta misma semana, ha habido una carrera de PR para mover eso a estable. Así que vi eso aparecer y pensé, oh, no, tengo que cambiar mi charla, pero sí, ese PR está abierto, así que la discusión está comenzando, así que parece que la bandera de mapas de origen habilitados podría volverse estable pronto. Y la otra que definitivamente ha progresado o se dirige en la dirección correcta para volverse estable son los recursos asíncronos y el almacenamiento local asíncrono. Actualmente hay mucha discusión, discusión activa sobre la definición de los criterios para que salgan de la etapa estable entre los colaboradores y contribuyentes. Así que las dos que veo venir a continuación son los mapas de origen habilitados y los recursos asíncronos y el almacenamiento local. Increíble, grandes características nuevas. Siguiente pregunta, ¿hay alguna adición de características que, con una historia interesante, puedas compartir? No tanto sobre implementaciones técnicas, sino cómo cobró vida y cosas así. Sí, una que siempre me pareció interesante fue la función de informe de diagnóstico. Entonces, la función de informe de diagnóstico, puedes configurar tu aplicación para que escriba un archivo cuando se bloquea o experimenta ciertos tipos de problemas y lo que el informe de diagnóstico proporciona es una función similar a los archivos principales de Java. Así que obtendrías ese archivo con información sobre cómo se veía tu aplicación en el momento en que se bloqueó y eso puede ayudarte a diagnosticar cualquier problema en tu aplicación. Y esa función en realidad era originalmente un módulo externo llamado informe de nodo y el problema que veíamos era que la gente no había instalado este módulo cuando lo activaba, su aplicación se bloqueaba pero luego necesitaban volver atrás, implementar nuevamente su aplicación con este módulo instalado y la función activada y luego esperar a que se reproduzca el bloqueo para obtener ese archivo nuevamente. Así que a menudo no estaba allí cuando la gente lo necesitaba y lo que sucedió es que el módulo externo de informe de nodo se fusionó en el núcleo de Node para tratar de aumentar la adopción y asegurarse de que esa función estuviera dentro del tiempo de ejecución en sí cuando la gente necesitara activarla para diagnosticar problemas y es muy interesante, creo que ese PR fue uno de nuestros PR más comentados, tuvo como casi mil comentarios y revisiones en el PR, así que es un PR grande. Wow, así que esa característica no la conocía, pero parece que podría reemplazar completamente a empresas como New Relic y cuál es la otra, como esta que olvido, pero como New Relic, ¿verdad? Las estás matando. Se trata realmente de socializar que las personas pueden activar esto y enseñar a las personas cómo pueden inspeccionar el archivo de diagnóstico y extraer la información que realmente es relevante para su bloqueo. Creo que eso va a ser un gran desafío para superar eso. Sí, pero es genial tenerlo. La siguiente pregunta es, ¿puedes compartir algunas características nuevas emocionantes que podemos esperar para Node 16? Sí, Node 16 saldrá en abril. Tenemos dos versiones principales. Sí, 16 será la que se promocione a LTS. En cuanto a las nuevas características y las versiones principales porque estamos haciendo la línea de versiones actual, por ahora Node 15 y estamos lanzando nuevas características cada dos semanas, cuando llegue a 16.0.0 no tendemos a lanzar muchas características nuevas porque naturalmente se han recogido en la línea de versiones actual y se han enviado a nuestros usuarios así que las únicas cosas que esperan para el lanzamiento de 16.0.0 son los cambios incompatibles o las actualizaciones realmente importantes que van a causar incompatibilidades en la API y por eso han tenido que esperar hasta ese lanzamiento de 16.0.0. Pero lo que siempre se garantiza que se incluya es una importante actualización de v8, por lo que es probable que se actualice v8 y dependiendo de qué versión de v8 se incluya puede traer consigo algunas nuevas características del lenguaje JavaScript, así que eso es lo principal
Deprecation Flag and Release Process
La bandera de deprecación throw es más adecuada para anticipar deprecaciones durante el desarrollo que para cargas de trabajo en producción. Bethany compartió su historia de desarrollo, incluyendo su interés en el arte digital y su pasantía en IBM. Explicó el proceso de las nuevas versiones de Node y la implementación de características, involucrando los estándares TC39 y el grupo de trabajo de lanzamiento de Node.js. El ajustado cronograma de lanzamiento de dos versiones principales por año presenta desafíos, especialmente para los cambios incompatibles. La política LTS brinda soporte a largo plazo para que las empresas actualicen a su propio ritmo. La comunidad de Node está dispuesta a ayudar a los usuarios que están atascados en versiones específicas y encontrar rutas de migración. La disposición de la industria para compartir experiencia y ayudar a los demás es notable. La sesión de preguntas y respuestas concluyó con agradecimientos a Bethany por sus conocimientos y una promesa de una futura broma de Volver al Futuro.
Si estás buscando en una nueva versión principal. Eso es genial. La siguiente pregunta es de fried zoidberg. ¿Es apropiada la bandera de deprecación throw para cargas de trabajo en producción o es más adecuada para anticipar deprecaciones durante el desarrollo? Sí, personalmente me inclinaría hacia lo último. Cuando algo se deprecia, probablemente no quieras que tu aplicación de repente comience a fallar en producción. Definitivamente es más adecuado para obtener el tipo de prueba preliminar para ver qué hará tu aplicación en desarrollo. Sí, para que estés preparado para las próximas actualizaciones. Muy bien, veamos la siguiente pregunta. Un poco fuera de tema, pero también lo es. Siempre me intriga cómo la gente se involucra en el desarrollo. ¿Puedes compartir un poco, como al comienzo del día le preguntamos a todos cuánto tiempo llevas desarrollando profesionalmente? Así que ¿puedes compartir un poco sobre tu historia de desarrollo? Sí, claro, desde joven siempre me interesó el arte digital y también incursioné un poco en el desarrollo web, pero cuando fui a la universidad realmente comencé a aprender y me gustó más el lado del código. Hice algo un poco inusual, pasé mi año sabático haciendo una pasantía en IBM trabajando con las APIs de Java Websphere y cosas así, así que realmente fue ese año sabático en la industria lo que me ayudó a descubrir lo que me gustaba y lo que no, y eso me llevó por este camino y luego después de la universidad me uní a IBM, fui asignada a su equipo de Node Runtime y he estado allí casi cinco años y ahora estoy en el mismo equipo pero en Red Hat, así es como me involucré con la comunidad de código abierto y cosas así. ¿Tu trabajo de código abierto y el comité TC39 es algo que puedes hacer en horario de trabajo? Sí, definitivamente. Parte de mi rol y responsabilidades es ayudar en la comunidad de Node, ayudar a garantizar que las plataformas de IBM, Red Hat y los sistemas operativos funcionen correctamente en Node, pero también ayudar en general y contribuir a la comunidad de Node, como ayudar a producir lanzamientos y cosas así. Genial, y para las personas que no saben mucho sobre, bueno, tal vez algunas personas están viendo esto y ni siquiera saben qué significa realmente TC39, ¿puedes explicar cómo es el proceso para que salgan estas nuevas versiones de Node y se implementen las nuevas características? ¿Cómo es ese proceso? Bueno, creo que hay dos cosas sutiles. Están los estándares TC39 que pasan por las propuestas y agregan nuevas características de lenguaje JavaScript, y luego tenemos dentro del espacio de Node.js, el grupo de trabajo de lanzamiento de Node.js, y son responsables de auditar los commits y características que se incorporan en el tiempo de ejecución de Node y determinar en qué líneas de lanzamiento deberíamos enviarlos y con qué frecuencia deberíamos hacer lanzamientos, y cuando estamos auditando los commits individuales, estamos considerando si esta característica parece estable, si ha introducido alguna regresión conocida, si hay alguna implicación de rendimiento reportada en esto, así que realmente estamos tomando una visión más abstracta de los cambios que se están realizando en el tiempo de ejecución de Node y determinando si es seguro enviarlos en las diferentes líneas de lanzamiento. Entiendo, y mencionaste que hacen dos lanzamientos principales al año, ¿verdad? ¿Y cómo te sientes acerca de este ajustado cronograma? Por lo general, trabajo en iteraciones de dos semanas, así que eso es un poco más corto, pero a veces siento que eso juega en tu contra, ¿verdad? Si retrasaras tu lanzamiento, no sé, dos semanas más, entonces esta nueva característica increíble se lanzaría en la versión principal y ahora está en el estante durante medio año. Entonces, ¿cómo sientes que funciona este sistema? Sí, hay algunos desafíos, y normalmente si una nueva característica... si hay un cambio incompatible dentro de una nueva característica, a veces ese cambio tendrá que permanecer en la rama principal de nuestro repositorio hasta que salga el próximo lanzamiento principal. Eso puede ser un desafío. En algunos casos, hemos intentado, o los colaboradores y colaboradores de Node han intentado retroportar las nuevas características de una manera en la que no sean incompatibles, para que podamos llevarlas de vuelta a las otras líneas de lanzamiento. Pero sí, es un desafío. La política LTS se basa realmente en dar a las personas tiempo para actualizar y brindar ese soporte a largo plazo, creo que son alrededor de 30 meses, para que las empresas que no pueden manejar la actualización cada año o dos veces al año tengan tiempo para hacerlo. Y esto, mencionaste que es soporte a largo plazo, pero ¿es algo por lo que las empresas tienen que obtener una licencia, o es simplemente...? No, esta es la política central de Node sobre cuánto tiempo responderemos a las actualizaciones críticas y de seguridad, y eso es a lo que la comunidad intenta mantenerse como objetivo para todos. Sí, sí, está bien. Pero nuevamente, como mencionamos al principio de nuestra charla, si tienes problemas más adelante, es probable que la comunidad sea increíble y te ayude de todos modos, incluso si todavía estás utilizando, digamos, Node 5, y sí, sí. Si necesitamos ayuda, es probable que las personas aún estén dispuestas a ayudar. Sí, seguro. Si las personas están atascadas en una versión específica, definitivamente es algo para comunicarse con la comunidad de Node y explicar, porque si estás atascado en eso, es probable que haya muchos otros usuarios atascados por esa razón, y tal vez podamos encontrar una ruta de migración o un cambio que facilite esa ruta de migración. Sí, eso es realmente genial. Nuevamente, no conozco ninguna otra industria que esté tan dispuesta a compartir su experiencia con la competencia, ¿verdad? Así que cualquier persona, incluso organizando este tipo de congreso, donde las personas simplemente comparten todo lo que saben y quieren ayudar a las personas a avanzar en sus carreras. Es algo increíble, y no puedo imaginar ninguna otra industria donde eso suceda. Así que eso es realmente genial. Y con eso, creo que vamos a terminar esta sesión de preguntas y respuestas. Entonces, Bethany, muchas gracias por brindarnos información sobre el futuro. Aún no he pensado en mi broma de Volver al Futuro, así que tal vez la pensaré y la tuitearé más tarde. Bethany, muchas gracias y espero verte de nuevo pronto. Gracias. Adiós.
Comments