Hacia una Biblioteca Estándar para Runtimes de JavaScript

Rate this content
Bookmark

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

James Snell
James Snell
34 min
17 Feb, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Existe la necesidad de una biblioteca estándar de APIs para los runtimes de JavaScript, ya que actualmente existen múltiples formas de realizar tareas fundamentales como la codificación base64. Históricamente, los runtimes de JavaScript 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, con algunos runtimes abusando de él para limitar la innovación. Existe una desalineación entre Node y los navegadores web en términos de funcionalidad y estándares de API. La propuesta es involucrar a los desarrolladores de navegadores en conversaciones sobre la estandarización de API y crear una biblioteca estándar común para los runtimes 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 los trabajadores de Cloudflare tienen sus propias API. Necesitamos una biblioteca estándar de API para los entornos de ejecución de JavaScript. Comencemos con una discusión sobre la codificación base64 en Node.

Hola, Congreso de Node. Soy James Snell, o JA Snell en GitHub o Twitter. Y estoy con CloudFlare. También estoy en el comité de dirección técnica de node. He estado contribuyendo a Node durante casi siete años. Comencé en 2015, justo cuando NodeJS y IOJS estaban teniendo sus problemas y los reuní. Así que han estado alrededor por un tiempo. Y en ese tiempo, ha habido algunos temas que se han desarrollado con el tiempo. Ya sabes, tenemos todos las API de node que existen. Ya sabes, hemos añadido un montón de nuevas características a node. Añadimos soporte para HTTP2 y nuevo análisis de URL. Recientemente, acabamos de añadir soporte para streams web, así que la API de stream legible y escribible. Creo que hace dos años, implementamos la API de Web Crypto. Así que, ya sabes, ha pasado mucho. Y durante ese tiempo, ya sabes, hemos tenido este tipo de debate y conversación continua sobre cuán estandarizadas deberían ser las API de Node o cuánto de las standards de la plataforma web Node debería estar prestando atención. Bueno, ya sabes, desde ese tiempo, ya sabes, hemos tenido otros entornos de ejecución que han surgido. Hemos tenido Deno, ya sabes, que es una plataforma fabulosa y fantástica. Pero tiene, ya sabes, su propio conjunto de API. Tenemos los trabajadores de Cloudflare, uno de los entornos de ejecución en los que estoy trabajando ahora. Ya sabes, y tiene su conjunto de API y cosas que hace. Y, ya sabes, hay otros entornos que puedes, ya sabes, mirar Fastly o mirar en, ya sabes, algunos de los dispositivos IoT, ya sabes, hay un montón de lugares donde JavaScript se está utilizando ahora. Así que, sí, tienes que parar y pensar, ya sabes, en algún momento, es bueno siempre dar un paso atrás y pensar, ¿qué tipo de API deberíamos estar implementando? Bueno, estoy aquí, ya sabes, después de, ya sabes, siete años de hacer esto, ya sabes, aquí con una propuesta un poco modesta. Necesitamos una biblioteca estándar de API para los entornos de ejecución de JavaScript. Voy a hablar un poco sobre, ya sabes, por qué estoy pensando eso y, ya sabes, qué tipo de cosas me gustaría ver. Así que, comencemos. Aquí hay un rompecabezas. Ya sabes, la codificación base64 es algo muy común en muchas aplicaciones. Lo vemos en todas partes. En Node, ya sabes, siempre hemos tenido esto, ya sabes, buffer desde hola a cadena base64. Podemos, ya sabes, tomar un

2. Codificación Base64 en JavaScript

Short description:

¿Cuál es la forma correcta de codificar en base64 los 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 añade fricción y dificultad a los desarrolladores. El módulo Base64.js es ampliamente utilizado, a pesar de que 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 a partir de ella. Pero, ya sabes, ¿cuál es la forma correcta de codificar en base64 los data desde JavaScript, verdad? Hay esto, ya sabes, personas que han estado desarrollando el navegador durante mucho tiempo, ya sabes, probablemente están familiarizados con esta función B2A. ¿Es la forma correcta? Quiero decir, es el único estándar que tenemos para la codificación base64, pero honestamente, es bastante malo. No maneja todo lo que necesitas y simplemente funciona más o menos bien. Pero realmente no podemos cambiarlo debido a la compatibilidad hacia atrás y todas esas cosas. Entonces, ¿cuál es la forma correcta de hacer la codificación 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 es algo que está en NPM, verdad? Donde, ya sabes, tienes que salir y, ya sabes, instalar algún módulo de NPM una vez que lo encuentres, una vez que encuentres el correcto. Y con suerte, encuentras uno que esté, ya sabes, bien mantenido, que tenga un contribuyente activo, al menos, ya sabes, un contribuyente activo que lo mantenga actualizado y en movimiento y asegure que sigue funcionando con Node y diferentes versiones de Node o diferentes versiones de Deno o, ya sabes, 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, ya sabes, pero tener tantas formas diferentes de hacer algo que es tan fundamental simplemente añade fricción, añade dificultad a los desarrolladores que están escribiendo code 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 dependientes. Y muchos de esos son aplicaciones de Node, a pesar del hecho de que Node tiene esto incorporado, ¿verdad? Pero también un gran número de esas dependencias son, ya sabes, aplicaciones de navegador, que, ya sabes, todo lo que tienen que confiar incorporado es B2A. Y, ya sabes, B2A en sí mismo carece de bastante funcionalidad. 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 de hacerlo

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

Short description:

¿Y si quisiéramos tener codificación Base64 URL? ¿Por qué no hay una única API para la codificación hex en JavaScript? ¿Existe una API estándar para comparar subconjuntos de rangos binarios? ¿Cómo manejan diferentes plataformas la acumulación de datos de transmisión? Históricamente, los entornos de ejecución de JavaScript han sido anti-biblioteca estándar.

de hacerlo. ¿Y si quisiéramos tener codificación Base64 URL, verdad? Que es una variante de Base64. Resulta que, incluso eso, de Base64 a Base64 URL, hay diferencias en las APIs. No todas las opciones funcionan. A veces, tenemos que cambiar algunas cosas. Afortunadamente, tanto Deno como Node tienen esto incorporado como parte de sus bibliotecas centrales. Y al menos esos funcionarán de manera consistente entre sí. Pero aún así, empiezas a tener muchas de estas opciones. Entonces, surge una pregunta muy importante. ¿Por qué algo tan común y tan ampliamente utilizado en JavaScript tiene tantas formas diferentes de hacerlo? ¿Y por qué debería importar qué entorno de ejecución de JavaScript estoy utilizando? ¿Por qué debería, como desarrollador, escribiendo JavaScript necesitar saber, está bien, ¿este code se va a ejecutar en Node o se va a ejecutar en DNO? ¿Cuál de estas bibliotecas básicas para codificar, APIs necesito usar? Oh, espera, ahora la prioridad de mi empresa ha cambiado, ahora están invirtiendo en computación en el borde. Ahora va a pasar a los trabajadores de Cloudflare. ¿Cuál de estas APIs funcionará allí? ¿O cómo hago para que funcione allí? ¿O necesito cambiar todo mi code que hace la 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 consuma tanto tiempo para simplemente Base64 y un poco de texto. ¿Qué pasa con la codificación hex? ¿Cuáles son las APIs para eso? Node lo hace de una manera, y, de nuevo, 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, de nuevo, esperas que se esté manteniendo. Pero, ¿con qué frecuencia nos encontramos con la codificación hex? Está en todas partes. Lo vemos por todas partes. Entonces, de nuevo, ¿por qué es tan difícil encontrar una única API para hacer la codificación hex en JavaScript? No tiene sentido. Bueno, ¿y si queremos ver otra funcionalidad, comparar subconjuntos de dos rangos binarios diferentes? Digamos que quieres, 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 comparando 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. Y desafortunadamente, Node y Dino, dos formas completamente diferentes de hacer esto, y simplemente no tiene sentido. ¿Y si estamos acumulando datos de transmisión en una transmisión simple, verdad? Queremos transmitir algunos datos, construir una cadena a partir de ellos. ¿Cómo hacemos eso en las diferentes plataformas? De nuevo, diferentes APIs. Funciona de manera diferente. No necesita ser así. Los entornos de ejecución de JavaScript históricamente han sido muy anti-biblioteca estándar. Este pensamiento realmente, proviene de, esta idea, la exploraremos un poco, la idea del núcleo pequeño. El principio subyacente aquí, quiero decir, la idea detrás de esto, la teoría detrás de esto es que, dejen que el ecosistema, 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 entornos de ejecución pequeños y sin opiniones. Desafortunadamente, este enfoque dificulta el desarrollo. Tienes que 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 fricción 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 entornos de ejecución pequeños, ¿verdad? Ya sabes, mantenlos sin opiniones. Solo implementa el mínimo indispensable que proporciona el lenguaje. Desafortunadamente, eso no facilita la vida al desarrollador. Hace las cosas bastante más difíciles. Tienes que encontrar la implementación de estas cosas. Tienes que seleccionar cuál de varias vas a usar. Asegúrate de que se está manteniendo. Asegúrate de que no introduce 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, tener seguridad vulnerabilidades inyectadas en ellos. Existe el riesgo de que no se mantenga al día con una versión particular de Node o Deno o workers o lo que sea y algo se rompe. Ya sabes, había algunos módulos que recientemente en bibliotecas de renderizado del lado del servidor que están construidos sobre un modelo antiguo de APIs de complementos nativos para Node. Bueno, ese modelo antiguo ya no es compatible y, ya sabes, una vez que pasas de Node 16 en adelante, no funcionan tan bien o en absoluto. Ya sabes, cuando empiezas a recoger estas APIs, ¿cómo sabes que van a seguir funcionando a medida que evolucionan los tiempos de ejecución? ¿Verdad? Así que esta idea de núcleo pequeño, vamos a dejar que los desarrolladores decidan es básicamente solo una forma diferente de decir que vamos a hacer este problema de los desarrolladores. Ya sabes, no vamos a pensar en ello. Vamos a obligaros a pensar en ello. Así que esta idea de, ya sabes, no tener una biblioteca estándar para JavaScript ha causado bastante fricción. Ahora bien, ha permitido una gran cantidad de evolución, ciclos más rápidos, mucha experimentación y un crecimiento realmente rápido. Pero

5. La Idea del Núcleo Pequeño

Short description:

La idea del núcleo pequeño es proporcionar APIs mínimas y confiar en fuentes externas para la funcionalidad adicional. Este enfoque hace que los entornos de ejecución como Node sean más pequeños y fáciles de mantener, pero traslada la responsabilidad de encontrar la funcionalidad faltante a los desarrolladores.

simplemente termina añadiendo dolores de cabeza a la mayoría de los desarrolladores. Bien, esta idea del núcleo pequeño. De nuevo, lo que básicamente significa es que las APIs que tu entorno de ejecución proporciona son lo más mínimas posible. Esencialmente la idea es, solo hacer lo que JavaScript hace, más un poco más. Y luego lo que falta, simplemente irías a npm o a 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 puedas encontrarlo, y simplemente encontrar esa funcionalidad adicional faltante en otro lugar. Esto permite que entornos de ejecución como Node sean más pequeños, nos da menos cosas que mantener con el tiempo. Pero de nuevo, simplemente patea la lata un poco más adelante, y dice que no es nuestro problema, es tu problema, si necesitas un poco de funcionalidad que no está allí.

6. Abuso del Núcleo Pequeño en los Entornos de Ejecución

Short description:

La idea del núcleo pequeño ha sido abusada e interpretada erróneamente para limitar la innovación en los entornos de ejecución de JavaScript. Siempre que surgía una API estándar, siempre había resistencia a añadir estas novedades al entorno de ejecución.

La idea del núcleo pequeño ha sido abusada e interpretada erróneamente para limitar la innovación en los entornos de ejecución de JavaScript. Siempre que surgía una API estándar, por ejemplo, con Node, siempre había este argumento, nah, nah, eso puede ser implementado 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 siempre, y luego el W3C desarrolló esta API de criptografía web, que hace muchas de las mismas cosas exactas, pero de una manera completamente diferente, que la API de Node. Los desarrolladores empezaron a usarla y empezaron a preguntar, hey Node, ¿puedes implementar la criptografía web? Y la respuesta fue no, núcleo pequeño, núcleo pequeño, si quieres eso, ve y lo implementas tú mismo. Aquí están los complementos nativos, aquí están las formas de hacerlo, pero nosotros no vamos a hacer eso. Y eso terminó limitando la compatibilidad entre Node y los entornos de ejecución del navegador y otros entornos de ejecución. Es donde todavía 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, sabes, esa, esa constante lucha cuesta arriba por intentar meter estas cosas en Node para evolucionar esa plataforma. Y luego ves algo como Dino que llega y dice, sabes qué, hey, vamos a apostar todo en los estándares web, vamos a hacer streams web, vamos a hacer criptografía web desde el principio. Los desarrolladores miran eso y dicen, bueno, hey, lo hicieron en Node, ¿por qué no puedes hacer esto? Y de nuevo, vuelve al núcleo pequeño, ¿verdad? Sabes, hubo esta constante, años y años y años de resistencia a añadir estas cosas nuevas

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 en streaming, datos binarios y criptografía. Sin embargo, estas plataformas hacen las cosas de formas completamente diferentes, causando fricción para los desarrolladores. El conflicto entre Node y los navegadores web ha sido constante, 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 entorno de ejecución. Hay otro argumento y esto es realmente desde el primer día de mi participación con Node, y he estado escuchando esto, Node no es un navegador web, no debería actuar como tal, 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 puede parecer. Sí, Node no tiene un proceso de renderizado, no va a salir y analizar HTML y renderizarlo en una ventana. Hay un montón de cosas que Node hace que los navegadores web no hacen, y hay un montón de cosas que los navegadores web hacen que Node no hace. Así que, sabes, sí, la afirmación es factualmente cierta, pero ignora un concepto muy fundamental de que Node y los navegadores web hacen muchas de las mismas cosas exactas. Ambos se utilizan para implementar aplicaciones en la web. Ambos necesitan trabajar con datos en streaming. Ambos necesitan trabajar con datos binarios. Ambos necesitan hacer criptografía. Hay una gran cantidad de superposición en la funcionalidad entre estos entornos, y no estoy hablando solo de Node, sabes, esto incluye Deno, esto incluye entornos como Cloudflare Workers. Hay una gran cantidad de superposición entre estas plataformas. Entonces, ¿por qué estas plataformas hacen las cosas de formas completamente diferentes, sabes, 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 básicamente decir 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 tampoco han demostrado realmente que les importen mucho los desarrolladores de Servidores y Edge. Los navegadores web básicamente se juntan y deciden una API y salen y dicen que esta es la norma para esto. Y todos ustedes, desarrolladores, salgan y usen eso. Y cuando, sabes, aquellos de nosotros que estamos trabajando en Node y Edge y decimos, bueno, espera, eso no funciona realmente bien o ya tenemos una API para esto. ¿Por qué no usaste eso? 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 eso es, sabes, históricamente eso es, sabes, ha habido este conflicto de ida y vuelta entre estos entornos, sabes, durante bastante tiempo. Y realmente se reduce a esta idea. Bueno, sabes, sí, todo es JavaScript, pero vamos a hacerlo de una manera diferente. Sí, sabes, ambos somos entornos de ejecución que funcionan en un servidor en algún lugar, pero vamos a hacerlo a la manera de Deno o vamos a hacerlo a la manera de Node. Y realmente no tiene sentido. Y simplemente causa fricción para los desarrolladores. Un ejemplo de esto, el módulo de stream legible en NPM tiene 105 millones de descargas por semana con más de 3,100 dependientes. 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 tocado Node, probablemente uses una aplicación que está utilizando el módulo de flujo legible. La elección de cada entorno de ejecución de hacer lo suyo tiene costos muy reales y causa un dolor muy 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 siendo 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 uno 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é API son las mejores es lo que necesitas, es algo que los propios entornos de ejecución necesitan hacer. Absolutamente deberíamos elegir un ganador cuando se trata de API si no lo hacemos los desarrolladores sufren.

Sabes, pero se usa en todas partes en muchas aplicaciones diferentes. Incluso si nunca has tocado Node, probablemente uses una aplicación que está utilizando el módulo de flujo legible. La elección de cada entorno de ejecución de hacer lo suyo tiene costos muy reales y causa un dolor muy real para los desarrolladores. Sabes, ¿el módulo de flujo legible, verdad? Cuando decidimos cambiar una API en Node, ese módulo tiene que cambiar eso causa, sabes, y eso se filtra hacia abajo a todos los demás que lo están usando, incluso si no están usando Node, ¿verdad? El módulo de flujo legible las decisiones que tomamos sobre qué otras dependencias en Node son necesarias se filtran hacia abajo. Entonces, sabes, el flujo legible usa la API de buffer, lo que significa que no puedes simplemente incorporar la API de flujo legible en Node, o en dno o en cualquier otro entorno. También tienes que incorporar el buffer. El flujo legible también se basa en la idea de Node del emisor de eventos. Lo que significa que tienes que incorporar el emisor de eventos en dno y, sabes, trabajadores y navegadores. Entonces, sabes, esta elección que Node hizo para tener esta API, y el hecho de que tanta gente la está usando, incluso si nunca han tocado Node, arrastra una gran 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, retrocediendo lo que esto significa es, sabes, Node es un entorno de ejecución y hay este ecosystem de desarrolladores que están creando cosas en el- que se ejecutan en ese entorno de ejecución. 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 siendo los desarrolladores principales de Node, no deberíamos decidir cuál de estos modules en npm la gente debería usar. Si hay dos implementaciones diferentes de un framework web, por ejemplo, sabes, no deberíamos tener una opinión sobre cuál es mejor o no deberíamos, sabes, favorecer a 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 añadiendo fricción a los desarrolladores. Y la fricción de la que estoy hablando es decidir cuál de estos deberías usar realmente, 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 vas a terminar teniendo que reescribir tu aplicación o las cosas van a dejar de funcionar o te vas a quedar en una versión más antigua de Node que podría tener security vulnerabilities porque no puedes actualizar porque requiere la mitad de tu aplicación para escribir, no para ser reescrita. Es un problema fundamental y no es uno que debamos tomar a la ligera. Bueno, voy a decir justo desde el principio, lo siento, esta idea es incorrecta. Es algo en lo que nos equivocamos con Node. Es algo en lo que yo había, es una filosofía en la que había comprado. Pero con el tiempo, he llegado a darme cuenta de que esta idea entera es incorrecta. Necesitamos tener una opinión. Tener una opinión es bueno. En el entorno de ejecución, tener una opinión sobre qué API son las mejores es lo que necesitas, es algo que los propios entornos de ejecución necesitan 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 la implementación de la misma. Absolutamente deberíamos elegir un ganador cuando se trata de API si no lo hacemos

9. Estandarización de la API Buffer

Short description:

Buffer es una API específica de Node que precede a los arrays de tipo. Era la única API para trabajar con datos binarios brutos en JavaScript. Hoy en día, Buffer extiende Uint8Array, pero hay diferencias en la funcionalidad. La API Buffer debería ser estandarizada para evitar que las decisiones sean tomadas únicamente por los contribuyentes de Node.

los desarrolladores sufren. Un case study de esto es la API Buffer de Node. Buffer es una API específica de Node, que precede a los arrays de tipo. Cuando se añadió Buffer, era la única API para trabajar con datos binarios brutos data en JavaScript. Hoy en día, Buffer extiende Uint8Array, más o menos. El slice de Buffer funciona de manera diferente. Tienes Buffer includes, o está buscando subrangos mientras que Uint8Array no lo hace. ToString funciona de manera diferente entre Buffer y Uint8Array. Probablemente hay más aplicaciones utilizando Buffer en el mundo que las que utilizan Uint8Array. El polyfill de Buffer solo en npm tiene 44 millones de descargas a la semana, por lo que esta es una API significativa. Pero está totalmente dirigida por las decisiones de Node. La necesidad de trabajar con binario no se limita a Node, pero todas las decisiones sobre lo que sucede con esa API son tomadas solo por Node, impactando a millones de desarrolladores, incluyendo a aquellos de ustedes que no están usando Node en absoluto. Y eso parece mal. Eso definitivamente me parece mal. La API Buffer debería ser estandarizada. Las decisiones que impactan la API no deberían ser tomadas solo por los contribuyentes de Node, aunque

10. Propuesta para la Estandarización de la API

Short description:

Las rutinas de JavaScript no deberían introducir nuevas APIs específicas de rutina a menos que sea absolutamente necesario. Debería haber una conversación entre diferentes rutinas 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 rutinas se pongan al día e involucren a los desarrolladores de navegadores en estas conversaciones.

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

11. APIs específicas de Runtime y Node vs Web Streams

Short description:

Las APIs específicas de runtime que deben ser polirellenadas y otros entornos son un error. Los streams de Node y los streams web son ambas APIs complejas. Los streams de Node son ampliamente utilizados y complicados, pero aún funcionan bien. Los streams web tienen un nivel similar de complejidad y realizan las mismas tareas. Las decisiones tomadas por Node y el what WG impactan a desarrolladores en todo el mundo.

conversaciones también. No importa de qué runtime estemos hablando. Las APIs específicas de runtime que deben ser polirellenadas y otros entornos son un error, ¿verdad? Si ellas necesitan estar 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. Los streams de Node versus los streams web. Aquí hay un gran ejemplo de esto. Los streams de Node preceden al estándar de stream de W3C. Ha estado alrededor por años. Hay tres diferentes versiones de streams de Node en una implementación. Es una de las APIs más antiguas y complicadas en Node. Y también es una de las más ampliamente utilizadas en todo el ecosistema. Los streams de Node son un lío excesivamente complicado de código y APIs que son horribles de usar, pero aún funcionan realmente, realmente bien.

Los streams web. Mira la complejidad de los streams de Node en lugar de sostener mi cerveza. Parece que podría ser una API más fácil. Pero bajo la superficie, es en realidad una API muy, muy complicada. Los streams web no son menos complicados que los streams de Node. Tienen aproximadamente el mismo nivel de complejidad, hacen las mismas cosas. Se podría argumentar que los streams web nunca necesitaron existir. Simplemente lo hiciste de la manera en que Node lo hizo. Pero, ya sabes, estamos donde estamos hoy. Tenemos dos diferentes modelos de API de streams en uso en JavaScript. Los streams de Node son más rápidos que los streams web, pero ambos hacen exactamente lo mismo. Node controla todas las decisiones sobre qué cambios se hacen a los streams de Node. Bien. Y de nuevo, como dije, esas decisiones impactan a millones de desarrolladores alrededor del mundo, ya sea que usen Node o no. El what WG por otro lado controla todas las decisiones sobre los cambios a los streams web y el what WG no es solo una única organización. Es un proceso abierto para participar aquí. Pero, what WG explícitamente prioriza las necesidades de los navegadores web sobre todas las otras plataformas. Ha causado problemas. Bien.

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

Short description:

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

Necesita haber más cooperación. Entonces, ya sabes, démos un paso atrás. ¿Cuál es la API de streams de Deno? Son web streams. Correcto. ¿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 estándar de streams para JavaScript, sin importar cuánto pataleen y se quejen los desarrolladores de Node? Debería ser web streams. Vale. Y los iteradores asíncronos. Esa es otra historia. Esa es una conversación diferente que tener. Pero, no importa que los streams de Node sean tan populares. El estándar, el que todos deberían estar usando, es web streams. Y esa es la dirección hacia la que deberíamos

13. La Biblioteca Estándar Deano

Short description:

La llaman biblioteca estándar. Sería mejor si no fuera específica para Deano. Agregar APIs estándar no significa cambiar o eliminar las existentes. Node debería seguir el ejemplo de Dino de tener una biblioteca estándar de APIs comunes que no necesariamente están incorporadas en el tiempo de ejecución. Todas las ejecuciones de JavaScript deberían compartir una biblioteca estándar común de APIs que funcionen de manera consistente en múltiples plataformas.

deberíamos encaminarnos. La biblioteca estándar Deano. Solo tengo que hacer un punto. La llaman una biblioteca estándar. Realmente es solo un conjunto de APIs específicas de Deano. La llaman una biblioteca estándar para Deano mismo. Idea brillante. Sería mejor si no fuera específica para Deano. Y si miras a través de la implementación, hay varios lugares donde es muy específico para Deano. Sabes, es algo que podemos hacer mejor, ¿verdad? Es algo en lo que podemos seguir iterando. Una pregunta clave aquí, ¿qué pasa con la compatibilidad hacia atrás? 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 estar usando. Pero URL parse no va a ninguna parte. Todavía está ahí. Solo tiene un montón de errores y algunas preocupaciones de seguridad. Y hay muchas razones por las que no deberías usarlo. Pero si lo usas, seguirá funcionando. Agregar estas cosas nuevas no significa deshacerse de las viejas, ¿verdad? Pero Node debería seguir el ejemplo de Dino de tener una biblioteca estándar de APIs comunes que no necesariamente están incorporadas en el tiempo de ejecución, ¿verdad? Sabes, estas todavía podrían ser cosas que instalas a través de NPM. Pero están bendecidas por Node. Y implementan APIs comunes que también funcionan en Dino, que también funcionan en Edge, entornos Edge como workers, que funcionan en cualquiera de estas ejecuciones, ¿verdad? Se basan en APIs estándar que funcionan de manera consistente en múltiples plataformas. Estos no deberían ser específicos para Node de ninguna manera, ¿verdad? No deberían ser específicos para Dino de ninguna manera. Todas las ejecuciones de JavaScript deberían compartir una biblioteca estándar común de APIs que funcionen de manera consistente, que no necesariamente sean parte del lenguaje, pero que aún proporcionen funcionalidad común en la parte superior. ¿De qué funcionalidad estamos hablando? Hay bastante. Hay bastante aquí. Y definitivamente la mayoría de estos no pertenecen realmente al lenguaje en sí. 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 código abierto, preferiblemente impulsado por contribuyentes tanto de Node, Deno, y otras ejecuciones de JavaScript como los trabajadores de CloudFlare. Desarrollar una biblioteca común de APIs.

QnA

Biblioteca Estándar y Contribuyentes del Núcleo de Node

Short description:

Tomar lo que Deno ha comenzado con su biblioteca estándar y expandirlo a un entorno multiplataforma y de múltiples tiempos de ejecución. 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án seguros sobre las APIs que se están utilizando. Ahora, pasemos a las preguntas. ¿Algún miembro del núcleo de Node forma parte de W3C W3C, WG o TC39? Node en sí no puede unirse a estas organizaciones, pero los contribuyentes individuales del núcleo de Node están activos en TC39 W3C.

Así que básicamente toma 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. Expande eso a algo que es verdaderamente cross-platform, verdaderamente un entorno de múltiples tiempos de ejecución que funciona para Node. Funciona para Deno. Funciona para los trabajadores. Y funcionará para cualquier entorno que elija soportar las APIs de la biblioteca estándar. Las implementaciones subyacentes pueden ser diferentes. Nadie dice que estas tienen que ser implementadas de la misma manera exacta. Pero las APIs en sí mismas deben ser claras, consistentes y comunes en todos estos diferentes entornos. De todos modos, se me acabó el tiempo. Así que, esa es mi modesta propuesta. Espero con interés las conversaciones en torno a esto y ver hasta dónde podemos llegar. Y espero que todos disfruten el resto de la conferencia. Adiós.

Entonces, veamos los resultados de la encuesta. Entonces, James preguntó, si tus ubicaciones de JavaScript ¿utilizas polyfills para las APIs de Node.js o Deno? El 41% respondió que no, el 32% respondió que no sabe, y el 25% respondió que sí. ¿Qué te parece esta encuesta, James? ¿Es lo que esperabas? Es más o menos lo que esperaba. Ese 33% y el no sé. Es realmente interesante que un tercio de la gente simplemente no está segura de qué APIs se están utilizando y si hay cosas de Node ahí o no y de dónde vienen esas cosas. Es muy interesante. Genial. Así que ahora, pasemos a las preguntas. La gente todavía puede hacer preguntas en el Node Talk Q&A en el canal de Discord. Tenemos una de Com Frarial. ¿Algún miembro del núcleo de Node forma parte de W3C W3C, WG o TC39? Sí, absolutamente. Así que lo único que puedo describir es que Node en sí es parte de la JS Foundation, que es un cierto tipo de organización sin fines de lucro en los Estados Unidos. No puede, debido al tipo de organización que es, Node en sí no puede unirse a TC39, y no puede unirse a W3C como organización. Pero los individuos sí pueden, individuos que trabajan para empleadores como IBM o Cloudflare o lo que sea, donde estas empresas podrían estar involucradas con estos grupos, entonces pueden participar. Así que tenemos contribuyentes individuales del núcleo de Node que están muy activos en TC39 W3C. Y Whatwg es, ya sabes, no tienes que ser miembro

Relevancia de las APIs de Navegador y el Desarrollo de Node

Short description:

Los navegadores exponen un gran número de APIs estandarizadas, muchas de las cuales son relevantes para los desarrolladores de servidores y edge. APIs como URL, compression stream, decompression stream, streams, crypto, WebSocket, File y Blob son comunes a múltiples plataformas. Si bien algunas APIs de la plataforma web pueden no ser relevantes, existe una superposición significativa. El desarrollo de front-end y Node.js requieren diferentes mentalidades. El orador está trabajando en la implementación del protocolo quick para Node, que se espera que aterrice a mitad de año.

de una empresa o cualquier cosa, cualquiera puede participar en eso. Hemos estado activos en muchas de esas conversaciones. Gracias. Gracias por tu respuesta. Tenemos otra pregunta. Los navegadores exponen un gran número de APIs estandarizadas para los usuarios. ¿Cuántas de esas APIs son realmente relevantes para los desarrolladores de servidores y edge que ejecutan Node.js, Deno o entornos de computación edge como Cloud para Workers? Bastantes de ellas. Y cualquiera que haya estado prestando atención a Node por un tiempo y Deno y Workers. Sabes, hemos visto muchas APIs como URL, ¿verdad? Compression stream, decompression stream como Deno acaba de lanzar decompression stream creo que en 1.9 hoy creo. Están todas las APIs de streams, todas las APIs de crypto. Están las APIs de WebSocket. Están, ya sabes, File y Blob y ya sabes que hay un gran número de estas cosas que son relevantes. Que representan funcionalidades que son comunes a todas estas plataformas. Así que ya sabes, sí, hay muchas de las APIs de la plataforma web que simplemente nunca van a ser relevantes, ¿verdad? Como no creo que vayamos a ver nunca, ya sabes, como APIs de renderización de medios allí, pero sí, donde hay superposición, definitivamente hay muchas APIs que podemos mirar. Gracias. Y tenemos un comentario aquí de JsCars diciendo que ciertamente tiene razón, la mayoría de las veces necesito dos mentalidades. Una cuando trabajo en desarrollo front-end y otra cuando estoy trabajando 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 ahora o cualquier característica? Para Node, estoy trabajando en tratar de implementar el protocolo quick, así que vamos a estar trabajando en eso bastante más en los próximos meses y esperamos que eso aterrice probablemente a mitad 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 aprendan mucho también. ¡Nos vemos! Gracias por invitarme.

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

Scaling Up with Remix and Micro Frontends
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.
Design Systems: Walking the Line Between Flexibility and Consistency
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.
Full Stack Components
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.
Making JavaScript on WebAssembly Fast
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.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
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.
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
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

Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Hussien Khayoon
Kahvi Patel
2 authors
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.
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
Top Content
WorkshopFree
Sam Sycamore
Siriwat (Jun) Kunaporn
2 authors
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.js Masterclass
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Top Content
Workshop
Matteo Collina
Matteo Collina
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
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
Gleb Bahmutov
Gleb Bahmutov
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.
Build and Deploy a Backend With Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Matteo Collina
Matteo Collina
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.
0 to Auth in an Hour Using NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
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