Hacia una Biblioteca Estándar para Tiempos de Ejecución de JavaScript

Rate this content
Bookmark

Puedes revisar las diapositivas de la charla de James aquí.

34 min
17 Feb, 2022

Video Summary and Transcription

Existe la necesidad de una biblioteca estándar de APIs para tiempos de ejecución de JavaScript, ya que actualmente existen múltiples formas de realizar tareas fundamentales como la codificación base64. Los tiempos de ejecución de JavaScript históricamente han carecido de una biblioteca estándar, lo que ha causado fricción y dificultades para los desarrolladores. La idea de un núcleo pequeño tiene tanto beneficios como inconvenientes, ya que algunos tiempos de ejecución lo utilizan de manera abusiva para limitar la innovación. Existe una falta de alineación entre Node y los navegadores web en cuanto a funcionalidad y estándares de API. La propuesta es involucrar a los desarrolladores de navegadores en conversaciones sobre la estandarización de las API y crear una biblioteca estándar común para los tiempos de ejecución de JavaScript.

Available in English

1. Introducción a la Estandarización de la API de Node.js

Short description:

Hola, Congreso de Node. Soy James Snell, o JA Snell en GitHub o Twitter. He estado contribuyendo a Node durante casi siete años. Hemos tenido debates continuos sobre la estandarización de la API de Node y su alineación con los estándares de la plataforma web. Otros entornos de ejecución como Deno y Cloudflare Workers tienen sus propias API. Necesitamos una biblioteca estándar de API para entornos de ejecución de JavaScript. Comencemos con una discusión sobre la codificación base64 en Node.

a Node durante casi siete años. Comencé en 2015, justo cuando NodeJS e IOJS estaban teniendo sus problemas y los uní nuevamente. Así que han estado aquí por un tiempo. Y durante ese tiempo, han surgido algunos temas. Sabes, tenemos todas las API de Node que existen. Hemos agregado muchas nuevas funciones a Node. Agregamos soporte para HTTP2 y un nuevo análisis de URL. Recientemente, agregamos soporte para transmisiones web, como las API de transmisión legible y transmisión escribible. Hace dos años, implementamos la API de Web Crypto. Así que, sabes, ha sucedido mucho. Y durante ese tiempo, hemos tenido este debate y esta conversación continua sobre cuán estandarizadas deberían ser las API de Node o cuánto de los estándares de la plataforma web standards Node debería prestar atención. Bueno, desde ese momento, han surgido otros entornos de ejecución. Tenemos Deno, que es una plataforma fabulosa y fantástica. Pero tiene su propio conjunto de API. Tenemos Cloudflare Workers, uno de los entornos de ejecución en los que estoy trabajando actualmente. Y tiene su conjunto de API y cosas que hace. Y, sabes, hay otros entornos que puedes, sabes, mirar Fastly o mirar IoT dispositivos, sabes, hay muchos lugares donde se está utilizando JavaScript ahora. Así que, sí, tienes que detenerte y pensar, sabes, en algún momento, es bueno dar un paso atrás y pensar, ¿qué tipo de API deberíamos implementar? Bueno, estoy aquí, sabes, después de siete años haciendo esto, aquí con una modesta propuesta. Necesitamos una biblioteca estándar de API para entornos de ejecución de JavaScript. Voy a hablar un poco sobre por qué estoy pensando eso y, sabes, qué me gustaría ver. Así que, comencemos. Aquí hay un acertijo. Sabes, la codificación base64 es algo muy común en muchas aplicaciones. Lo vemos en todas partes. En Node, sabes, siempre hemos tenido esto, sabes, buffer de hello a string base64. Podemos, sabes, tomar un

2. Codificación Base64 en JavaScript

Short description:

¿Cuál es la forma correcta de codificar en base64 datos desde JavaScript? La respuesta es todas ellas. La API buffer de Node, la API de Deno o algo de NPM. Sin embargo, tener tantas formas diferentes de hacer algo fundamental agrega fricción y dificultad para los desarrolladores. El módulo Base64.js es ampliamente utilizado, aunque Node tiene una opción incorporada. Ninguna de estas es la forma correcta porque siempre hay una forma diferente de hacerlo.

cadena codificada en base64 y obtener nuestro buffer de vuelta. Pero, ya sabes, ¿cuál es la forma correcta de codificar en base64 data desde JavaScript, ¿verdad? Hay esto, ya sabes, personas que han estado desarrollando el navegador durante mucho tiempo, ya sabes, probablemente están familiarizadas con esta función B2A. ¿Es la forma correcta? Quiero decir, es el único estándar que tenemos para la codificación en base64, pero honestamente, es un poco malo. No maneja todo lo que necesitas y simplemente funciona bien. Pero realmente no podemos cambiarlo debido a la compatibilidad con versiones anteriores y todas esas cosas. Entonces, ¿cuál es la forma correcta de hacer la codificación en base64 en JavaScript? ¿Es la API buffer de Node? ¿Es la API de Deno, ya sabes, donde importas esta función de codificación de su biblioteca estándar? ¿O es, ya sabes, la respuesta algo en NPM, ¿verdad? Donde, ya sabes, tienes que ir y, ya sabes, instalar algún módulo una vez que lo encuentres, una vez que encuentres el correcto. Y con suerte, encuentras uno que esté, ya sabes, bien mantenido, tenga un contribuyente activo que lo mantenga actualizado y en movimiento y asegure que siga funcionando con Node y diferentes versiones de Node o diferentes versiones de Deno u otros entornos de ejecución. Ya sabes, y cuál es, ya sabes, una vez que tienes el mecanismo básico, ya sabes, ¿cuál API aquí es la correcta? Desafortunadamente, la respuesta es todas ellas. Todas ellas son la forma correcta de hacerlo, ya sabes, pero tener tantas formas diferentes de hacer algo tan fundamental solo agrega fricción, agrega dificultad para los desarrolladores que están escribiendo código que se ejecuta en la web. Sorprendentemente, esta cuarta opción, este módulo Base64.js, ya sabes, tiene más de 30 millones de descargas por semana desde NPM y tiene más de 1,300 dependencias. Y muchas de esas son aplicaciones de Node, a pesar de que Node tiene esto incorporado, ¿verdad? Pero también un gran número de esas dependencias son, ya sabes, navegadores, aplicaciones de navegadores que, ya sabes, que todo lo que tienen disponible es B2A. Y, ya sabes, B2A en sí mismo carece de muchas funcionalidades. Entonces, ya sabes, la respuesta es, ya sabes, todas estas son la forma correcta, pero ninguna de ellas es la forma correcta porque siempre hay una forma diferente

3. Desafíos con la Codificación y Operaciones Binarias

Short description:

¿Qué pasa si queremos tener codificación Base64 URL? ¿Por qué no hay una única API para la codificación hexadecimal en JavaScript? ¿Existe una API estándar para comparar subconjuntos de rangos binarios? ¿Cómo manejan las diferentes plataformas la acumulación de datos de flujo? Las ejecuciones de JavaScript históricamente han carecido de una biblioteca estándar.

de hacerlo. Sabes, ¿qué pasa si queremos tener codificación Base64 URL, ¿verdad? Que es una variante de Base64. Bueno, resulta que, sabes, incluso eso, sabes, de Base64 a Base64 URL, hay diferencias en las APIs. No todas las opciones funcionan. Sabes, a veces, sabes, tenemos que cambiar algunas cosas. Afortunadamente, tanto Deno como Node tienen esto incorporado como parte de sus, sabes, bibliotecas principales. Y al menos esos funcionarán de manera consistente entre sí. Pero aún así, sabes, comienzas a tener muchas de estas opciones. Entonces, surge una pregunta muy importante. ¿Por qué algo tan común y ampliamente utilizado en JavaScript tiene tantas formas diferentes de hacerlo? Y ¿por qué debería importar qué runtime de JavaScript estoy usando? ¿Por qué debería, como desarrollador, escribir JavaScript necesitar saber, está bien, ¿este código se ejecutará en Node o se ejecutará en Deno? ¿Cuál de estas bibliotecas básicas para la codificación, APIs debo usar? Oh, espera, ahora la prioridad de mi empresa ha cambiado, ahora están invirtiendo en computación en el borde. Ahora se ejecutará en los trabajadores de Cloudflare. ¿Cuál de estas APIs funcionará allí? ¿O cómo hago que funcione allí? ¿O necesito cambiar todo mi código que hace codificación Base64 para hacer algo completamente nuevo? Eso es ridículo, ¿verdad? Que algo tan común tenga que ser una conversación tan difícil y que consume tanto tiempo para simplemente Base64 y un poco de texto. ¿Qué pasa con la codificación hexadecimal? ¿Cuáles son las APIs para eso? Node lo hace de una manera, y, nuevamente, es consistente con la forma en que hace Base64. Deno lo hace a su manera, que es consistente con sus APIs. No hay nada que puedas usar en el navegador a menos que encuentres algún módulo aleatorio en npm, y, nuevamente, esperes que se esté manteniendo. Pero, ¿con qué frecuencia nos encontramos con la codificación hexadecimal? Está en todas partes. Vemos esto en todas partes. Sabes, entonces, nuevamente, ¿por qué es tan difícil encontrar una única API para hacer codificación hexadecimal en JavaScript? No tiene sentido. Bien, ¿qué pasa si queremos ver otra funcionalidad, comparar subconjuntos de dos rangos binarios diferentes, ¿verdad? Digamos que quieres, sabes, ver si una secuencia binaria está incrustada en otra secuencia binaria. ¿Cuál es la API para hacer esto? ¿Existe una API estándar para hacer esto? Bueno, desafortunadamente, los arrays tipados y JavaScript no hacen esto. No tienen, sabes, comparación de subconjuntos de diferentes rangos binarios. Todo lo que puedes hacer es mirar un miembro individual, un elemento individual, en un array tipado y compararlo con otro elemento individual en otro array tipado. Eso es todo lo que puedes hacer. Sabes, y desafortunadamente, Node y Deno, dos formas completamente diferentes de hacer esto, y sabes, simplemente no tiene sentido. ¿Qué pasa si estamos acumulando datos de flujo en un flujo simple, ¿verdad? Queremos, sabes, transmitir algunos datos en, construir una cadena a partir de ellos. ¿Cómo hacemos eso en las diferentes plataformas? Nuevamente, diferentes APIs. Funciona de manera diferente. No debería ser así. Las ejecuciones de JavaScript históricamente han sido muy anti-biblioteca estándar. Este pensamiento realmente, sabes, proviene de, sabes, esta idea, la exploraremos un poco, sabes, la idea del núcleo pequeño. Sabes, el principio subyacente aquí, quiero decir, la idea detrás de esto, la teoría detrás de esto es que, sabes, simplemente deja que el ecosistema, sabes, todos ustedes, todos los desarrolladores, hagan lo que quieran hacer, ¿verdad? Elijan cualquier dependencia

4. Desafíos con el Enfoque de Núcleo Pequeño

Short description:

Haz la elección que mejor se adapte a tu situación. Mantén los runtimes pequeños y sin opiniones. Desafortunadamente, este enfoque dificulta el desarrollo. Debes encontrar y seleccionar implementaciones, asegurar el mantenimiento y la seguridad, y lidiar con problemas de compatibilidad. La falta de una biblioteca estándar para JavaScript ha causado fricciones y dolores de cabeza para los desarrolladores.

funciona para ti. Haz la elección que, ya sabes, se adapte mejor a tu situación particular. Y mantén los runtimes pequeños, ¿verdad? Sabes, mantenlos sin opiniones. Solo implementa lo mínimo indispensable que el lenguaje proporciona. Desafortunadamente, eso no facilita la vida para el desarrollador. Lo complica bastante. Debes encontrar la implementación de estas cosas. Debes seleccionar cuál de varias vas a usar. Asegúrate de que se esté manteniendo. Asegúrate de que no introduzca ningún riesgo de seguridad. Es software de código abierto. Hay ejemplos de, ya sabes, módulos en NPM que han sido secuestrados. Ya sabes, que tienen vulnerabilidades de seguridad inyectadas en ellos. Existe el riesgo de que no se mantenga actualizado con una versión específica de Node o Deno o workers y algo se rompa. Ya sabes, hubo algunos módulos que hace poco tiempo en bibliotecas de renderizado en el lado del servidor que están construidos sobre un antiguo modelo de APIs de complementos nativos para Node. Bueno, ese antiguo modelo ya no es compatible y, ya sabes, una vez que pasas a Node 16 en adelante, ya no funcionan bien o en absoluto. Ya sabes, cuando comienzas a utilizar estas APIs, ¿cómo sabes si seguirán funcionando a medida que los runtimes evolucionen? ¿Verdad? Entonces, esta idea de un núcleo pequeño, vamos a dejar que los desarrolladores decidan, básicamente es una forma diferente de decir que vamos a hacer que esto sea un problema de los desarrolladores. Ya sabes, no vamos a pensar en ello. Vamos a obligarlos a ustedes a pensar en ello. Entonces, esta idea de, ya sabes, la falta de una biblioteca estándar para JavaScript ha causado bastante fricción. Ahora, concedido, ha permitido mucha evolución, ciclos más rápidos, mucha experimentación y un crecimiento muy rápido. Pero

5. La idea de un núcleo pequeño

Short description:

La idea de un núcleo pequeño es proporcionar APIs mínimas y depender de fuentes externas para funcionalidades adicionales. Este enfoque hace que los runtimes como Node sean más pequeños y más fáciles de mantener, pero traslada la responsabilidad de encontrar funcionalidades faltantes a los desarrolladores.

simplemente termina añadiendo dolores de cabeza a la mayoría de los desarrolladores. Bueno, entonces esta idea de un núcleo pequeño. Nuevamente, lo que esto básicamente significa es que las APIs que tu runtime proporciona son lo más mínimas posibles. Esencialmente, la idea es hacer solo lo que JavaScript hace, más un poco más. Y luego, lo que falte, simplemente buscarlo en npm o en algún otro registro en algún lugar, algún sitio web en algún lugar, o algún otro repositorio de GitHub o donde sea puedas encontrarlo, y simplemente encontrar esa funcionalidad faltante adicional en otro lugar. Esto permite que los runtimes como Node sean más pequeños, nos da menos cosas que mantener con el tiempo. Pero nuevamente, solo aplaza el problema un poco más y dice que no es nuestro problema, es tu problema, si necesitas alguna funcionalidad que no está ahí.

6. Abuso del Núcleo Pequeño en Runtimes

Short description:

La idea de un núcleo pequeño ha sido abusada y malinterpretada para limitar la innovación en los runtimes de JavaScript. Siempre que se presentaba una API estándar, siempre había resistencia para agregar estas nuevas cosas al runtime.

La idea de un núcleo pequeño ha sido abusada y malinterpretada para limitar la innovación en los runtimes de JavaScript. Siempre que se presentaba una API estándar, por ejemplo, con Node, siempre había este argumento, nah, nah, eso se puede implementar en el ecosistema, no lo necesitamos aquí. Un ejemplo de eso sería la API de criptografía web, Node tiene una API de criptografía, la ha tenido desde siempre, y luego el W3C desarrolló esta API de criptografía web, que hace muchas de las mismas cosas, pero de una manera completamente diferente a la API de Node. Los desarrolladores comenzaron a usarla y comenzaron a preguntar, oye Node, ¿puedes implementar la criptografía web? Y la respuesta fue no, núcleo pequeño, núcleo pequeño, si quieres eso, ve e implémentalo tú mismo. Aquí están los complementos nativos, aquí están las formas de hacerlo, pero no lo haremos nosotros. Y eso terminó limitando la compatibilidad entre Node y los runtimes de los navegadores y otros runtimes. Aún estamos luchando con problemas de interoperabilidad entre estas cosas hoy en día, ahora que tenemos criptografía web en Node, pero fue esa resistencia, ya sabes, esa, esa constante batalla cuesta arriba para tratar de conseguir estas cosas en Node y hacer evolucionar esa plataforma. Y luego ves algo como Dino que llega y dicen, tú sabes qué, hey, nos estamos enfocando en los estándares web, estamos implementando transmisiones web, estamos implementando criptografía web desde el principio. Los desarrolladores ven eso y dicen, bueno, ellos lo hicieron en Node, ¿por qué no puedes hacer esto? Y nuevamente, se remonta al núcleo pequeño, ¿verdad? Sabes, hubo esta constante, años y años de resistencia para agregar estas nuevas cosas

7. Desalineación entre Node y los Navegadores Web

Short description:

Node y los navegadores web tienen una gran superposición en funcionalidad, incluyendo el trabajo con datos de transmisión, datos binarios y criptografía. Sin embargo, estas plataformas hacen las cosas de manera completamente diferente, lo que causa fricción para los desarrolladores. El conflicto entre Node y los navegadores web ha sido continuo, con cada lado insistiendo en hacer las cosas a su manera. Esta falta de alineación ha llevado a la creación de APIs específicas de Node que se utilizan ampliamente en diferentes plataformas.

en el runtime. Hay otro argumento y esto es realmente desde el primer día de mi participación con Node, y he estado escuchando esto, que Node no es un navegador web, no debería actuar como uno, no debería tener estas APIs que existen en el navegador. Hacen cosas diferentes y honestamente, están mucho más cerca de lo que parece. Sí, Node no tiene un proceso de renderizado , no va a analizar HTML y renderizarlo en una ventana. Hay muchas cosas que Node hace que los navegadores web no hacen, y hay muchas cosas que los navegadores web hacen que Node no hace. Entonces, sí, la afirmación es verdadera desde el punto de vista factual, pero ignora un concepto fundamental de que Node y los navegadores web hacen muchas de las mismas cosas. Ambos se utilizan para implementar aplicaciones en la web. Ambos necesitan trabajar con data de transmisión. Ambos necesitan trabajar con data binarios. Ambos necesitan hacer criptografía. Hay una gran superposición de funcionalidad entre estos entornos, y no solo estoy hablando de Node, esto incluye a Deno, esto incluye entornos como Cloudflare Workers. Hay una gran superposición entre estas plataformas. Entonces, ¿por qué estas plataformas hacen las cosas de manera completamente diferente, incluso cuando están en las áreas de superposición? No tiene sentido. El argumento se ha utilizado a lo largo de la historia para decir básicamente que está bien que Node haga todo a su manera. Incluso si los desarrolladores están haciendo exactamente las mismas cosas en los navegadores. Para ser justos, los navegadores web no han mostrado mucho interés en los desarrolladores de Servidor y Edge. Los navegadores web básicamente se reúnen y deciden sobre una API y salen y dicen que esta es la norma para esto. Y todos ustedes desarrolladores salen y la usan. Y cuando, ya sabes, aquellos de nosotros que trabajamos en Node y Edge decimos, bueno, espera, eso no funciona realmente bien o ya tenemos una API para esto. ¿Por qué no la usaste? La respuesta típicamente ha sido que no nos importa lo que estás haciendo. Esto es lo que los navegadores van a hacer. Ha mejorado un poco recientemente, pero históricamente, eso es, ya sabes, ha habido este conflicto de ida y vuelta entre estos entornos, ya sabes, durante bastante tiempo. Y realmente se está llegando a esta idea. Bueno, sí, todo es JavaScript, pero lo vamos a hacer de manera diferente. Sí, ya sabes, ambos runtimes se ejecutan en algún lugar de un servidor, pero lo vamos a hacer a la manera de Deno o lo vamos a hacer a la manera de Node. Y realmente no tiene sentido. Y solo causa fricción para los desarrolladores. Un ejemplo de esto es el módulo de transmisión legible en NPM, que tiene 105 millones de descargas por semana con más de 3,100 dependencias. Funciona en Node, funciona en Deno, funciona en Cloud para Workers y en todos los principales navegadores. Pero es una API específica de Node.

8. Desafíos con la Estandarización de API

Short description:

Incluso si nunca has usado Node, probablemente utilices una aplicación que utiliza el módulo de transmisión legible. La elección de cada entorno de hacer las cosas a su manera tiene costos reales y causa un dolor real para los desarrolladores. No deberíamos elegir un ganador es básicamente un concepto dentro de Node que dice que no deberíamos decidir, nosotros, los desarrolladores principales de Node, no deberíamos decidir qué módulos de npm deberían usar las personas. Es un problema fundamental y no es algo que debamos tomar a la ligera. Necesitamos tener una opinión. Tener una opinión es bueno. En el entorno de ejecución, tener una opinión sobre qué APIs son las mejores es lo que necesitas, es algo que los entornos de ejecución mismos deben hacer. Definitivamente deberíamos elegir un ganador cuando se trata de APIs, si no lo hacemos, los desarrolladores sufren.

Sabes, pero se usa en todas partes en muchas aplicaciones diferentes. Incluso si nunca has usado Node, probablemente utilices una aplicación que utiliza el módulo de transmisión legible. La elección de cada entorno de hacer las cosas a su manera tiene costos reales y causa un dolor real para los desarrolladores. Sabes, así que el módulo de transmisión legible, ¿verdad? Cuando decidimos cambiar una API en Node, ese módulo tiene que cambiar eso causa, sabes, y eso se transmite a todos los demás que lo están utilizando, incluso si no están usando Node, ¿verdad? El módulo de transmisión legible , las decisiones que tomamos sobre qué otras dependencias en Node son necesarias se transmiten . Entonces, sabes, los flujos legibles utilizan la API de búfer, lo que significa que no puedes simplemente importar la API de transmisión legible en Node, o en dno o en cualquier otro entorno. También tienes que importar el búfer. El módulo de transmisión legible también se basa en la idea de emisor de eventos de Node. Lo que significa que tienes que importar el emisor de eventos en dno y, sabes, en los trabajadores y los navegadores. Entonces, sabes, esta elección que Node hizo de tener esta API, y el hecho de que mucha gente la está utilizando, incluso si nunca, incluso si nunca han usado Node, arrastra una enorme cantidad de trabajo adicional y dolor adicional y esfuerzo adicional para los desarrolladores prácticamente en todas partes. Ya sea que estés usando Node o no.

Entonces, hay otra idea aquí de que no deberíamos elegir un ganador. Entonces, respaldando lo que esto significa es, sabes, Node es un runtime y hay este ecosistema de desarrolladores que están creando cosas en ese runtime. Y publican esas cosas en npm. Esta idea de que no deberíamos elegir un ganador es básicamente un concepto dentro de Node que dice que no deberíamos decidir, nosotros, los desarrolladores principales de Node, no deberíamos decidir qué de estos módulos en npm deberían usar las personas. Si hay dos implementaciones diferentes de un marco web , por ejemplo, sabes, no deberíamos tener una opinión sobre cuál es mejor o no deberíamos, sabes, favorecer uno sobre el otro. Básicamente, dejemos que el mercado decida, dejemos que los desarrolladores decidan. Todo lo que estamos haciendo es proporcionar una plataforma sobre la cual estas cosas se ejecutarán. La idea de esto, quiero decir, está bien en concepto, excepto cuando termina agregando fricción a los desarrolladores. Y la fricción de la que estoy hablando es decidir cuál de estos realmente deberías usar, cuál de estos se mantendrá a largo plazo, cuál de estos será realmente la inversión más segura para tu aplicación. Y cómo estás protegido contra tomar la decisión equivocada? ¿Cómo sabes que no terminarás teniendo que reescribir tu aplicación o que las cosas dejarán de funcionar o que te quedarás atrapado en una versión anterior de Node que podría tener vulnerabilidades de seguridad porque no puedes actualizar porque requiere que la mitad de tu aplicación se vuelva a escribir. Es un problema fundamental y no es algo que debamos tomar a la ligera. Bueno, voy a decirlo de una vez, lo siento, esta idea es incorrecta. Es algo en lo que nos equivocamos con Node. Es algo en lo que había creído. Pero a medida que ha pasado el tiempo, me he dado cuenta de que toda esta idea es incorrecta. Necesitamos tener una opinión. Tener una opinión es bueno. En el runtime, tener una opinión sobre qué APIs son las mejores es lo que necesitas, es algo que los entornos de ejecución mismos deben hacer. Cuando hay una necesidad común de algo, los entornos de ejecución deben favorecer una única API común y consistente mientras fomentan la competencia en su implementación. Definitivamente deberíamos elegir un ganador cuando se trata de APIs si no lo hacemos

9. Estandarización de la API de Buffer

Short description:

Buffer es una API específica de Node que precede a las matrices de tipos. Era la única API para trabajar con datos binarios en bruto en JavaScript. Hoy en día, el buffer se extiende a Uint8Array, pero hay diferencias en la funcionalidad. La API de buffer debería estandarizarse para evitar que las decisiones sean tomadas únicamente por los colaboradores de Node.

los desarrolladores sufren. Un estudio de caso de esto es la API de nodeBuffer. Buffer es una API específica de Node, precede a las matrices de tipos. Cuando se agregó el buffer, era la única API para trabajar con datos binarios en bruto en JavaScript. Hoy en día, el buffer se extiende a Uint8Array, en cierto modo. El método slice del buffer funciona de manera diferente. Tienes buffer.includes, o busca subrangos, mientras que Uint8Array no lo hace. ToString funciona de manera diferente entre buffer y Uint8Array. Probablemente haya más aplicaciones utilizando buffer en el mundo que Uint8Array. El polyfill del buffer solo en npm tiene 44 millones de descargas a la semana, por lo que esta es una API importante. Pero está completamente impulsada por las decisiones de Node. La necesidad de trabajar con datos binarios no se limita a Node, pero todas las decisiones sobre qué sucede con esa API son tomadas solo por Node, afectando a millones de desarrolladores, incluidos aquellos que no usan Node en absoluto. Y eso parece incorrecto. Definitivamente se siente incorrecto para mí. La API de buffer debería estandarizarse. Las decisiones que afectan a la API no deberían ser tomadas solo por los colaboradores de Node, aunque

10. Propuesta de Estandarización de la API

Short description:

Las implementaciones de JavaScript no deberían introducir nuevas APIs específicas del tiempo de ejecución a menos que sea absolutamente necesario. Debería haber una conversación entre las diferentes implementaciones para determinar si se necesita nueva funcionalidad y cómo implementarla de manera consistente. Los navegadores ya están haciendo esto a través de organizaciones como el W3C, y es hora de que Node y otras implementaciones se pongan al día e involucren a los desarrolladores de navegadores en estas conversaciones.

El buffer se originó como una API de Node. Muy bien, tengo una modesta propuesta. Las implementaciones de JavaScript no deberían introducir nuevas APIs específicas del tiempo de ejecución a menos que sea absolutamente necesario. Lo que esto significa es que cada vez que se necesita agregar alguna funcionalidad nueva, debería haber una conversación entre Node, Dino y todas estas diferentes implementaciones y decir `ok, ¿esto es algo que deberíamos hacer? ¿Es algo que los desarrolladores necesitan? ¿Cómo lo hacemos de manera consistente en todas estas implementaciones? Los navegadores ya están haciendo esto a través de organizaciones como el W3C y oneWG. Ya es hora de que Node, Dino y otros se pongan al día y es hora de que los desarrolladores de navegadores también se preocupen más por los servidores y los desarrolladores de bordes y participen en estas

11. Runtime-Specific APIs and Node vs Web Streams

Short description:

Las APIs específicas del tiempo de ejecución que deben ser emuladas en otros entornos son un error. Las secuencias de Node y las secuencias web son APIs complejas. Las secuencias de Node son ampliamente utilizadas y complicadas, pero aún funcionan bien. Las secuencias web tienen un nivel similar de complejidad y realizan las mismas tareas. Las decisiones tomadas por Node y el what WG afectan a los desarrolladores en todo el mundo.

Las conversaciones también son importantes. No importa de qué tiempo de ejecución estemos hablando. Las APIs específicas del tiempo de ejecución que deben ser emuladas en otros entornos son un error, ¿verdad? Si es necesario que estén en estos otros entornos, si los desarrolladores necesitan esta funcionalidad en múltiples lugares, entonces debería haber una API estándar. Y debería ser común. Secuencias de Node versus secuencias web. Aquí hay un gran ejemplo de esto. Las secuencias de Node existen desde antes del estándar de secuencias del what W3C. Ha estado presente durante años. Hay tres versiones diferentes de las secuencias de Node en una implementación. Es una de las APIs más antiguas y complicadas de Node. Y también es una de las más ampliamente utilizadas en todo el ecosistema. Las secuencias de Node son un desastre excesivamente complicado de código y APIs que son horribles de usar, pero aún funcionan realmente bien. Las secuencias web. Mira la complejidad de las secuencias de Node y luego imagina algo más complicado. Parece que podría ser una API más fácil. Pero en realidad, es una API muy, muy complicada. Las secuencias web no son menos complicadas que las secuencias de Node. Tienen un nivel similar de complejidad y hacen las mismas cosas. Se podría argumentar que las secuencias web nunca necesitaron existir. Simplemente se podría haber hecho de la misma manera que Node lo hizo. Pero, ya sabes, estamos donde estamos hoy. Tenemos dos modelos de API de secuencias diferentes en uso en JavaScript. Las secuencias de Node son más rápidas que las secuencias web, pero ambas hacen exactamente lo mismo. Node controla todas las decisiones sobre los cambios que se realizan en las secuencias de Node. Y como dije antes, esas decisiones afectan a millones de desarrolladores en todo el mundo, ya sea que usen Node o no. Por otro lado, el what WG controla todas las decisiones sobre los cambios en las secuencias web y el what WG no es solo una organización. Es un proceso abierto para participar aquí. Pero el what WG prioriza explícitamente las necesidades de los navegadores web sobre todas las demás plataformas. Esto ha causado problemas.

12. Cooperación y API de Streams Estándar

Short description:

La API de streams estándar para JavaScript debería ser web streams, independientemente de la popularidad de los streams de Node. Esta es la dirección en la que deberíamos estar avanzando.

Necesitamos más cooperación. Entonces, déjenme dar un paso atrás. ¿Cuál es la API de streams de Deno? Son web streams. ¿Cuál es la API de streams de CloudFlowerWorker? Correcto. Son web streams. ¿Cuál es la API de streams del navegador? Son web streams. Correcto. ¿Cuál debería ser la API de streams estándar para JavaScript B, sin importar cuánto los desarrolladores de Node insistan en usar streams, deberían ser web streams. Bien. Y los iteradores asíncronos, eso es otra historia. Esa es una conversación diferente. Pero no importa que los streams de Node sean tan populares. El estándar, el que todos deberían estar usando, son los web streams. Y esa es la dirección en la que deberíamos

13. The Deano Standard Library

Short description:

Lo llaman una biblioteca estándar. Sería mejor si no fuera específica de Deano. Agregar APIs estándar no significa cambiar o eliminar las existentes. Node debería seguir el ejemplo de Deano y tener una biblioteca estándar de APIs comunes que no necesariamente estén integradas en el tiempo de ejecución. Todos los entornos de ejecución de JavaScript deberían compartir una biblioteca estándar común de APIs que funcionen de manera consistente en múltiples plataformas.

ser el título. La biblioteca estándar de Deano. Solo quiero hacer un punto. Lo llaman una biblioteca estándar. En realidad, es solo un conjunto de APIs específicas de Deano. Lo llaman una biblioteca estándar para Deano en sí. Idea brillante. Sería mejor si no fuera específica de Deano. Y si observas la implementación, hay varios lugares donde es muy específica de Deano. Sabes, es algo en lo que podemos mejorar, ¿verdad? Es algo en lo que podemos seguir iterando. Una pregunta clave aquí, ¿qué pasa con la compatibilidad con versiones anteriores? Agregar APIs estándar no significa cambiar o eliminar las existentes. Un buen ejemplo de esto es URL parse y NewURL en Node. Ambos todavía existen en Node. NewURL es el que deberías usar. Pero URL parse no va a desaparecer. Todavía está ahí. Solo tiene algunos errores y algunassecurity preocupaciones. Y hay muchas razones por las que no deberías usarlo. Pero si lo usas, seguirá funcionando. Agregar estas cosas nuevas no significa deshacernos de las cosas antiguas, ¿verdad? Pero Node debería seguir el ejemplo de Deano y tener una biblioteca estándar de APIs comunes que no necesariamente estén integradas en el runtime, ¿verdad? Sabes, estas aún podrían ser cosas que instalas a través de NPM. Pero están aprobadas por Node. E implementan APIs comunes que también funcionan en Deano, que también funcionan en entornos de Edge, como los workers, que funcionan en cualquier de estos entornos de ejecución, ¿verdad? Se basan en APIs estándar que funcionan de manera consistente en múltiples plataformas. Estas no deberían ser específicas de Node de ninguna manera, ¿verdad? No deberían ser específicas de Deano de ninguna manera. Todos los entornos de ejecución de JavaScript deberían compartir una biblioteca estándar común de APIs que funcionen de manera consistente, que no sean necesariamente parte del lenguaje, pero aún brinden funcionalidad común adicional. ¿De qué funcionalidad estamos hablando? Hay bastante. Hay bastante aquí. Y definitivamente la mayoría de estas no deberían estar realmente en el propio lenguaje. Pero son cosas en las que podemos trabajar juntos para impulsar en la plataforma. Entonces, ¿qué necesitamos? Y este es el meollo de la modesta propuesta de la que estoy hablando. Un nuevo esfuerzo colaborativo de open-source, preferiblemente impulsado por colaboradores de Node, Deno y otros entornos de ejecución de JavaScript como los workers de CloudFlare. Desarrollar una biblioteca común de APIs.

QnA

Standard Library and Node Core Contributors

Short description:

Tomemos lo que Deno ha comenzado con su biblioteca estándar y ampliémoslo a un entorno multiplataforma y multi-runtime. Las implementaciones subyacentes pueden ser diferentes, pero las APIs deben ser claras, consistentes y comunes en todos los entornos. Los resultados de la encuesta muestran que un tercio de los encuestados no está seguro de las APIs que se están utilizando. Ahora, pasemos a las preguntas. ¿Hay miembros del núcleo de Node que formen parte de W3C, WG o TC39? Node en sí no puede unirse a estas organizaciones, pero los contribuyentes individuales del núcleo de Node son activos en TC39 y W3C.

Entonces, tomemos básicamente lo que Deno ha comenzado con su biblioteca estándar, que existe como un repositorio separado y piezas instalables por separado. Comencemos por ahí, tal vez. Ampliemos eso a algo que sea verdaderamente multiplataforma, verdaderamente un entorno multi-runtime que funcione para Node. Funciona para Deno. Funciona para los workers. Y funcionará para cualquier entorno que elija admitir las APIs de la biblioteca estándar. Las implementaciones subyacentes pueden ser diferentes. Nadie dice que estas tengan que implementarse de la misma manera exacta. Pero las APIs en sí deben ser claras, consistentes y comunes en todos estos diferentes entornos. De todos modos, se me acabó el tiempo. Esa es mi modesta propuesta. Espero con ansias las conversaciones sobre esto y ver a dónde podemos llegar. Y espero que todos disfruten del resto de la conferencia. Adiós.

Veamos ahora los resultados de la encuesta. James preguntó: si usas JavaScript en Node.js o Deno, ¿utilizas polyfills para las APIs de Node.js o Deno? El 41% respondió que no, el 32% respondió que no lo sabe y el 25% respondió que sí. ¿Qué opinas de esta encuesta, James? ¿Es lo que esperabas? Es más o menos lo que esperaba. Ese 33% y el `no lo sé`. Es realmente interesante que un tercio de las personas simplemente no estén seguras de qué APIs se están utilizando realmente y si hay cosas de Node allí o no y de dónde vienen esas cosas. Es muy interesante. Bien. Ahora, pasemos a las preguntas. Las personas aún pueden hacer preguntas en el canal de Discord de la charla de Node. Tenemos una de Com Frarial. ¿Hay miembros del núcleo de Node que formen parte de W3C, WG o TC39? Sí, absolutamente. Lo que puedo describir es que Node en sí forma parte de la JS Foundation, que es un tipo específico de organización sin fines de lucro en los Estados Unidos. No puede unirse a TC39 ni a W3C como organización debido al tipo de organización que es. Pero las personas individuales pueden hacerlo, personas que trabajan para empleadores como IBM o Cloudflare, donde estas empresas pueden estar involucradas con estos grupos, entonces pueden participar. Tenemos contribuyentes individuales del núcleo de Node que son muy activos en TC39 y W3C. Y Whatwg es, ya sabes, no tienes que ser miembro

Relevancia de las API de los navegadores y el desarrollo de Node

Short description:

Los navegadores exponen una gran cantidad de API estandarizadas, muchas de las cuales son relevantes para los desarrolladores de servidores y bordes. API como URL, compresión de flujo, descompresión de flujo, flujos, criptografía, WebSocket, archivo y blob son comunes en múltiples plataformas. Si bien algunas API de la plataforma web pueden no ser relevantes, hay una superposición significativa. El desarrollo de front-end y Node.js requiere mentalidades diferentes. El orador está trabajando en la implementación del protocolo rápido para Node, que se espera que se implemente a mediados de año.

de una empresa o cualquier otra persona puede participar en ella. Hemos estado activos en muchas de esas conversaciones. Gracias. Gracias por tu respuesta. Tenemos otra pregunta. Los navegadores exponen una gran cantidad de API estandarizadas para los usuarios. ¿Cuántas de esas API son realmente relevantes para los desarrolladores de servidores y bordes que ejecutan Node.js, Deno o entornos de cómputo de bordes como Cloud for Workers? Bastantes de ellas. Y cualquiera que haya estado prestando atención a Node durante un tiempo y a Deno y Workers. Sabes, hemos visto muchas API como URL, ¿verdad? Compresión de flujo, descompresión de flujo como Deno acaba de implementar la descompresión de flujo, creo que en la versión 1.9 de hoy, creo. Hay todas las API de flujos, todas las API de criptografía. Hay las API de WebSocket. Hay, ya sabes, Archivo y Blob y, ya sabes, hay una gran cantidad de estas cosas que son relevantes. Que representan funcionalidades comunes a todas estas plataformas. Así que, ya sabes, sí, hay muchas API de la plataforma web que simplemente nunca serán relevantes, ¿verdad? Como no creo que alguna vez veamos, ya sabes, API de renderizado de medios allí, pero sí, donde hay superposición, definitivamente hay muchas API que podemos analizar. Gracias. Y tenemos un comentario aquí de JsCars que dice que tiene toda la razón, la mayoría de las veces necesito dos mentalidades. Una cuando trabajo en desarrollo de front-end y otra cuando trabajo con Node.js. Así que sí, muchas gracias por tu charla. Ahora que trabajas en el núcleo de Node, ¿puedes decirnos cuál es el tema más interesante en el que estás trabajando actualmente o alguna característica? Para Node, estoy trabajando en tratar de implementar el protocolo rápido, así que vamos a trabajar en eso bastante más en los próximos meses y esperamos implementarlo probablemente a mediados de año. Wow, muy emocionante, muy emocionante. Espero que suceda pronto. Muchas gracias James. Espero que hayas disfrutado de esta conferencia y espero que los asistentes también hayan aprendido mucho. ¡Nos vemos! Gracias por tenerme.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.