Puedes revisar las diapositivas de la charla de James aquí.
This talk has been presented at Node Congress 2022, check out the latest edition of this JavaScript Conference.
FAQ
James Snell ha estado contribuyendo a Node durante casi siete años.
Recientemente se añadió soporte para streams web en Node.
James Snell propone la necesidad de una biblioteca estándar de API para los entornos de ejecución de JavaScript.
La principal preocupación es que tener muchas formas diferentes de hacer algo tan fundamental como la codificación base64 añade fricción y dificultad para los desarrolladores.
El modelo de 'núcleo pequeño' se critica por hacer la vida más difícil para los desarrolladores, ya que deben elegir entre múltiples implementaciones y mantenerse al día con las actualizaciones y la seguridad.
El módulo Base64.js tiene más de 30 millones de descargas por semana desde NPM.
Los entornos de ejecución de JavaScript enfrentan el problema de la incompatibilidad y la falta de estandarización de las API entre diferentes plataformas.
La API Buffer es específica de Node y se utiliza para trabajar con datos binarios. Es una API significativa que James Snell sugiere debería ser estandarizada.
La cooperación es importante para desarrollar APIs comunes y consistentes que funcionen en múltiples plataformas, simplificando el desarrollo y mantenimiento de aplicaciones.
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.
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.
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
WebAssembly enables optimizing JavaScript performance for different environments by deploying the JavaScript engine as a portable WebAssembly module. By making JavaScript on WebAssembly fast, instances can be created for each request, reducing latency and security risks. Initialization and runtime phases can be improved with tools like Wiser and snapshotting, resulting in faster startup times. Optimizing JavaScript performance in WebAssembly can be achieved through techniques like ahead-of-time compilation and inline caching. WebAssembly usage is growing outside the web, offering benefits like isolation and portability. Build sizes and snapshotting in WebAssembly depend on the application, and more information can be found on the Mozilla Hacks website and Bike Reliance site.
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
Durante esta masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debería conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final de la masterclass, los participantes ganarán una nueva confianza en su capacidad para escribir código JavaScript de alta calidad que resista el paso del tiempo. Puntos Cubiertos: 1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso Cómo Ayudará a los Desarrolladores: - Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y la comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento de la carrera y las oportunidades de avance en la industria del software
Sumérgete en el mundo de la IA con nuestro masterclass interactivo diseñado específicamente para desarrolladores web. "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" ofrece una oportunidad única para cerrar la brecha entre la IA y el desarrollo web. A pesar de la prominencia de Python en el desarrollo de IA, el vasto potencial de JavaScript sigue siendo en gran medida inexplorado. Este masterclass tiene como objetivo cambiar eso.A lo largo de esta sesión práctica, los participantes aprenderán cómo aprovechar LangChain, una herramienta diseñada para hacer que los modelos de lenguaje grandes sean más accesibles y útiles, para construir agentes de IA dinámicos directamente dentro de entornos JavaScript. Este enfoque abre nuevas posibilidades para mejorar las aplicaciones web con funciones inteligentes, desde el soporte al cliente automatizado hasta la generación de contenido y más.Comenzaremos con los conceptos básicos de LangChain y los modelos de IA, asegurando una base sólida incluso para aquellos nuevos en IA. A partir de ahí, nos sumergiremos en ejercicios prácticos que demuestran cómo integrar estas tecnologías en proyectos reales de JavaScript. Los participantes trabajarán en ejemplos, enfrentando y superando los desafíos de hacer que la IA funcione sin problemas en la web.Este masterclass es más que una experiencia de aprendizaje; es una oportunidad de estar a la vanguardia de un campo emergente. Al final, los asistentes no solo habrán adquirido habilidades valiosas, sino que también habrán creado funciones mejoradas con IA que podrán llevar a sus proyectos o lugares de trabajo.Ya seas un desarrollador web experimentado curioso acerca de la IA o estés buscando expandir tus habilidades en áreas nuevas y emocionantes, "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" es tu puerta de entrada al futuro del desarrollo web. Únete a nosotros para desbloquear el potencial de la IA en tus proyectos web, haciéndolos más inteligentes, interactivos y atractivos para los usuarios.
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
Top Content
WorkshopFree
2 authors
Usar una biblioteca puede parecer fácil a primera vista, pero ¿cómo eliges la biblioteca correcta? ¿Cómo actualizas una existente? ¿Y cómo te abres camino a través de la documentación para encontrar lo que quieres? En esta masterclass, discutiremos todos estos puntos finos mientras pasamos por un ejemplo general de construcción de un editor de código usando CodeMirror en React. Todo mientras compartimos algunas de las sutilezas que nuestro equipo aprendió sobre el uso de esta biblioteca y algunos problemas que encontramos.
Construye un Tablero Rico en Datos y Hermoso con la Rejilla de Datos de MUI X y Joy UI
Top Content
WorkshopFree
2 authors
Aprende cómo utilizar el ecosistema completo de MUI para construir un tablero de gestión de proyectos hermoso y sofisticado en una fracción del tiempo que tomaría construirlo desde cero. En particular, veremos cómo integrar la Rejilla de Datos de MUI X con Joy UI, nuestra biblioteca de componentes más nueva y hermana del estándar de la industria Material UI. Tabla de contenidos:- Presentando nuestro proyecto y herramientas- Configuración de la aplicación e instalación del paquete- Construcción del tablero- Prototipado, estilos y temas - Características de Joy UI- Filtrado, ordenación, edición - Características de la Rejilla de Datos- Conclusión, pensamientos finales, P&R
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.
Este masterclass te enseñará los conceptos básicos de cómo escribir pruebas de extremo a extremo utilizando Cypress Test Runner. Cubriremos la escritura de pruebas, abarcando todas las características de la aplicación, estructurando las pruebas, interceptando solicitudes de red y configurando los datos del backend. Cualquier persona que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir el masterclass.
JSNation 2024
Comments