Bun, Deno y muchos otros tiempos de ejecución de JavaScript han sido elogiados, pero ¿sabes por qué? ¿Es tan fácil crear un tiempo de ejecución desde cero?
He estado investigando el secreto detrás del poder de Node.js y por qué hay tantos nuevos tiempos de ejecución de JavaScript surgiendo. Desglosando cada componente clave utilizado en Node.js, he llegado a conclusiones interesantes que muchas personas solían decir, pero en la práctica funciona de manera un poco diferente.
En esta charla, los asistentes aprenderán los conceptos utilizados para crear un nuevo tiempo de ejecución de JavaScript. Pasarán por un ejemplo de cómo hacer un tiempo de ejecución de JavaScript siguiendo lo que está detrás de escena en el proyecto Node.js utilizando C++. Aprenderán la relación entre V8 de Chrome y Libuv y qué hace que un tiempo de ejecución de JavaScript sea mejor que otros.
Esta charla cubrirá los siguientes temas: - ¿Qué es un motor de JavaScript - V8 - ¿Por qué Node.js utiliza Libuv - Cómo crear un tiempo de ejecución de JS desde cero
This talk has been presented at Node Congress 2023, check out the latest edition of this JavaScript Conference.
FAQ
Node.js es un entorno de ejecución de JavaScript que utiliza V8 para interpretar JavaScript y libuv para manejar operaciones asíncronas. V8 se encarga de la gramática y los tipos de datos de JavaScript, mientras que libuv gestiona el bucle de eventos y la concurrencia.
El presentador intentó reimplementar Node.js, incluyendo características como WebSockets y la cobertura de código. También exploró la implementación de funciones como 'print' y 'setTimeout' en C++ y su integración en el contexto de V8.
Mencionar Node.js en una entrevista de trabajo puede ser crucial porque demuestra conocimiento en tecnologías de backend modernas y experiencia con sistemas asincrónicos y el manejo de eventos, habilidades valoradas en el desarrollo de software.
Funciones como 'setTimeout' y 'console.log' no son parte de ECMAScript y provienen del entorno de Node.js. Estas funciones son implementadas en C++ y expuestas a JavaScript a través de V8.
El presentador investigó en el sitio web oficial de Node.js, exploró enlaces y recursos disponibles allí, y realizó experimentos prácticos para entender mejor cómo funciona el bucle de eventos y la concurrencia en Node.js.
La curiosidad y el deseo de entender profundamente cómo funciona Node.js detrás de escena motivaron al presentador. Además, quería llenar un vacío de contenido sobre Node.js en internet, compartiendo su aprendizaje a través de tutoriales y un libro electrónico.
Libuv es una biblioteca que proporciona el soporte para las operaciones de entrada/salida asincrónicas en Node.js. Gestiona el bucle de eventos, permitiendo que Node.js realice operaciones no bloqueantes y maneje múltiples conexiones simultáneamente.
El presentador implementó nuevas funciones en Node.js escribiendo funciones de C++ y vinculándolas al contexto de V8. Utilizó un puente C++ para integrar estas funciones, permitiendo su uso en JavaScript.
La charla explora la magia detrás de Node.js y profundiza en sus componentes, incluyendo V8, libuv y el puente C++. Se discute el flujo de trabajo y el proceso de ejecución, el uso de NodeMod y la comprensión de las funciones de la consola. La charla también cubre las funciones y programación de Node.js, la introducción de tiempos de ejecución y la colaboración entre los tiempos de ejecución de JavaScript. Concluye con ideas sobre la producción de contenido, la elección de Node.js y la inspiración detrás de él.
Hoy, les hablaré sobre algunos experimentos, algunas ciencias locas que he estado haciendo usando JavaScript y muchas cosas más. Comencé a investigar sobre Node.js y encontré información contradictoria. Así que decidí crear un tutorial basado en mi propia investigación. Vamos a entender la magia detrás de Node.js y explorar el repositorio de Node.js.
Hoy, les hablaré sobre algunos experimentos, algunas ciencias locas que he estado haciendo usando JavaScript y muchas cosas más, y espero que les guste mucho este contenido porque fue un verdadero esfuerzo crear todo esto. Para comenzar, todo lo que les mostraré hoy ya está en línea, así que después de la charla les mostraré algunos enlaces para que puedan ir allí, pero por favor, si pueden, tomen una foto de esta charla, mencionen el evento, mencionenme porque esto nos ayuda mucho con el trabajo que hemos estado haciendo. Muy bien. Estoy muy emocionado, voy a hablar sobre Node.js y el creador de NodeJS está aquí, el bun, y así sucesivamente. Así que es bastante asombroso. Bueno, en primer lugar, he estado haciendo muchos otros experimentos. Estaba tratando de volver a implementar Node.js, re-implementando WebSockets, re-implementando la cobertura de código, así que he estado haciendo muchas preguntas específicas, así que estoy muy curioso, y todos estos tutoriales están allí para que también los encuentren. Bueno, todo este experimento comenzó cuando comencé a preguntarme, bueno, ¿realmente sé qué es Node.js? Así que comencé a investigar y descubrí que algunos artículos decían que V8 hace una cosa, Libuv hace otra, JavaScript tiene otro papel, y a veces un artículo era controvertido con otro, así que pensé, hmm, tal vez debería aprender más, tal vez debería entender mejor. Así que realmente no sé qué está sucediendo detrás de escena, cómo está funcionando realmente. Así que comencé a investigar un poco y descubrí que no hay contenido sobre esto. Nadie ha recreado todo esto, compilando todas las bibliotecas, pero comencé a investigar en el sitio web de Node.js, y esos enlaces me ayudaron mucho a aprender cómo funciona el bucle de eventos, cómo funciona el módulo de concurrencia en Node.js, pero aún así, quería más. Así que por eso creé este tutorial. Este es un tutorial completo paso a paso, en el que se basa esta charla, así que esta charla va a ser muchos aspectos destacados, porque no puedo mostrar todo práctico aquí. Así que pueden probarlo más tarde. Solo un aviso antes de continuar, voy a decirles, todo lo que hay aquí es parte de mi investigación, ¿de acuerdo? No soy un desarrollador de C++. Es posible que vean muchas malas prácticas allí, pero es algo que disfruté haciendo. Además, esto es parte de mi propia investigación. Como les dije, no hay contenido en Internet. Así que comencé a preguntar a algunos amigos, a mirar el código fuente y a hacer algunas suposiciones. Y solo un aviso, los autores de los JS Runtimers, son increíbles. Comencé a valorarlos más a medida que vi lo complejo que es detrás pueden usar JavaScript allí. Muy bien, vamos a la parte divertida, ¿verdad? Así que vamos a entender la magia detrás de Node.js. Todo esto, lo hice como un Gitpod. Hice todo el entorno para ustedes allí mismo. Son binarios y muchas cosas que pueden comenzar a usar de inmediato. Para comenzar, pensé, ¿qué pasa si voy al repositorio de Node.js y trato de encontrar cómo Ryan Doll estaba haciendo esto? Así que descubrí muchos archivos. Y descubrí como, oh, tal vez debería intentar reproducir esto, pero si ven, fue hace 14 años. Como muchas herramientas, ni siquiera funciona más. Pero aún así, ¿alguien ha visto este sitio web antes?
2. Introducción a los Componentes de Node.js
Short description:
Esta fue la primera versión lanzada de Node.js. Es la V001. Y puedes ver que en ese entonces no había console.log. Era puts. Muy bien. Traté de dividir los componentes principales para que puedas entender el papel de cada uno. Vamos a hablar sobre V8, libuv y el impresionante puente C++. Voy a intentar implementar una nueva función en el lado de V8. Echemos un vistazo a nuestro código JS y creemos una función de impresión en C++. Detrás de escena, V8 es como el evolucionador. Una función setTimeout es algo asíncrono, depende del entorno. Por eso Node.js es tan bueno, porque es extensible. La mayoría de los entornos de ejecución de JS siguen la misma idea. Voy a intentar hacer algunos experimentos usando nuestro código JavaScript. Aquí está todo el proyecto en C++.
Nadie. Esto es muy bueno. Esta fue la primera versión lanzada de Node.js. Es la V001. Y puedes ver que en ese entonces no había console.log. Era puts. Muy bien. Muy bien. Sé que este es un tema muy complejo, así que no te haré dormir aquí mismo, ¿de acuerdo? Así que traté de dividir los componentes principales para que puedas entender el papel de cada uno. Si estás buscando trabajo, esto es genial para mencionar en la entrevista.
Primero, vamos a hablar sobre V8. V8 es la gramática, son los tipos de datos de JavaScript, es cómo se interpreta JavaScript, lo que significa una clase, una variable, un tipo de datos, todo está en V8. También tenemos libuv. Libuv es la parte asíncrona de la que hemos estado hablando mucho. Pero solo piensa en ello como un while true que busca nuevos eventos y, si los hay, si hay eventos pendientes, los despacha todos y puedes comenzar a recibir más datos y así sucesivamente. Y aquí, para mí, está la parte asombrosa. El puente C++. Así que cuando intentes encontrar, te darás cuenta de que Node.js es casi todo en C++. Voy a intentar algo mágico contigo, intentando implementar una nueva función en el lado de V8. Así que echemos un vistazo a nuestro código JS. Cuando comienzas a usar V8 desde cero, nuestro contexto, nuestro disco global está vacío. Entonces no hay nada allí que podamos usar, pero voy a intentar implementar la función de impresión. Print no existe en JavaScript, ¿de acuerdo? Entonces, si quiero poder ejecutar esta función desde el lado de JavaScript, esto debe estar en V8. Así que usando el puente C++, voy a crear una función de impresión en C++, y luego la voy a vincular al contexto. Verás, diría que cada vez que vea esta cadena, voy a llamar a esta función de C++. Detrás de escena, V8 es como el evolucionador, ¿verdad? Está evaluando todo lo que quieres. Bien, vamos a intentar hacer algo más difícil. Una función setTimeout es algo asíncrono, depende del entorno, así que podemos usar uvstart, que son funciones de libuv. Hacemos exactamente lo mismo, mapeamos esta cadena a esta función de C++ y luego ya está disponible en V8. Te digo, esta fue la parte para mí como, oh dios mío, por eso esto es tan bueno, porque es extensible, ¿verdad? La mayoría de los entornos de ejecución de JS siguen la misma idea, extienden el entorno de ejecución de JavaScript y hacen muchas cosas geniales. Así que aquí mismo, voy a intentar hacer algunos experimentos usando nuestro código JavaScript. Aquí puedo
3. Flujo de Trabajo y Ejecución
Short description:
En esta parte, exploraremos el flujo de trabajo del proyecto. Comenzamos leyendo el archivo Index.js como una cadena y luego lo compilamos en instancias de C++. A continuación, examinamos la ejecución real y la espera de eventos. Este proceso implica evaluar el código y programar eventos.
ve el archivo Index.js y aquí está todo el proyecto en C++. Entonces, si vas allí, vamos a echar un vistazo al flujo de trabajo, cómo funciona. En primer lugar, tengo que leer un archivo, ¿de acuerdo? Como te estaba diciendo, el archivo Index.js es solo una cadena al final. Voy a tomar este archivo y luego voy a usar compile. Entonces, compile tomará toda la cadena y la transformará en instancias de C++. Y después de eso, vamos a ver la ejecución real detrás de eso y luego tenemos nuestra espera de eventos. Así que simplemente evaluamos todo el código y luego
4. Using NodeMod and Understanding Console
Short description:
Si vas al código fuente, verás que se lee el archivo desde C++. Para hacer este proyecto, pasé un mes tratando de crear una estructura para poder reutilizarla. Pensé, ¿qué tal si simplemente uso NodeMod para esperar cualquier cambio y luego actualizar nuestra aplicación? En primer lugar, ¿qué sucede si intentamos llamar a console.log? Todo lo que depende del entorno es parte de algo más. Echemos un vistazo a la impresión. Es agradable ver algo tan complejo y aún así usar algo que, para mí, era realmente primitivo.
programar y esperar eventos. Por eso estás aquí, te lo estaba diciendo. Y solo es cuestión de curiosidad. Si vas al código fuente, verás que se lee el archivo desde C++. Así que no estoy usando libuv aquí porque el punto de entrada, solo necesito la cadena. Así que no quiero esperar, no necesito esperar a ningún otro proceso. Muy bien. Para hacer este proyecto, pasé un mes tratando de crear una estructura para poder reutilizarla. Y tuve que compilar la biblioteca V8, que está en C++, y la libuv, que está en C. Así que puedes ver todos los encabezados allí. Así que si no eres desarrollador de C++, yo tampoco, ¿verdad? Así que solo puedes echar un vistazo a la estructura. Es una solución muy buena. Puedes ver que estaba usando libuv, básicamente estaba usando NodeMod para crear todas estas cosas allí, ¿verdad? Así que saltemos un poco para que puedas ver el NodeMod. No sé nada sobre las tooling en el JavaScript o en el lado de C++. Así que pensé, ¿qué tal si simplemente uso NodeMod para esperar cualquier cambio y luego actualizar nuestra aplicación? Así que uso make para ejecutar todos los pasos de mi archivo de configuración y genera un binario, y luego puedo ejecutar un archivo JavaScript. ¿De acuerdo? En primer lugar, ¿qué sucede si intentamos llamar a console.log? Fue lo primero que intenté hacer allí, y honestamente estaba luchando mucho. Así que si ejecutas console.log, podríamos ver en los registros que no sucede nada. ¿Verdad? Pensé, ¿por qué no está sucediendo? Sin embargo, si obtengo la función de impresión que implementé yo mismo y imprimo la consola, puedo ver un objeto allí. Y si intento ver todas las claves, están todas allí. Sin embargo, diría que son solo una interfaz, ¿verdad? Pero no están haciendo nada. Detrás de escena, setTimeout, setInterval, y console no son JavaScript. Entonces, todo lo que depende del entorno es parte de algo más. En realidad, está explicando JavaScript. Así que si intento usar setTimeout aquí, puedo ver que setTimeout no está definido. O si setInterval, tampoco está definido. Todo lo que es parte de esto en realidad proviene de otros grupos de trabajo. Así que podemos ver console, podemos ver todas las especificaciones, pero en realidad no es como ECMAScript, ¿verdad? No tenemos algo que el runtime deba seguir en este caso. Bueno, intentemos hacer algo mejor aquí. Echemos un vistazo a la impresión. Para mí, esto fue como, oh Dios mío, estoy usando printf, que usé el primer día de la universidad, ¿verdad? Es agradable ver algo tan complejo y aún así usar algo que, para mí, era realmente primitivo. Así que tengo esas Tengo la función de impresión, la misma idea que usé en todo el dibujo que hice. Así que tenemos una cadena
5. Node.js Functions and Scheduling
Short description:
Cada función en Node.js se instancia utilizando el mismo enfoque. JavaScript tiene algunas excepciones, como el tiempo que depende del entorno. Las plantillas de cadenas, los mapas, los operadores de propagación y las promesas están integrados en V8. Las promesas son envoltorios para devoluciones de llamada que ayudan a los desarrolladores a escribir un código mejor. setTimeout e setInterval implican programar funciones para su ejecución futura, con variables y referencias en su lugar. Se crea el temporizador de libuv para ejecutar la función y el resultado se envía de vuelta a JavaScript. Las promesas en JavaScript no son operaciones LibuV o asíncronas. El código UV ejecuta eventos y espera nuevos. Las promesas se pueden usar con async/await, ya que forman parte del lenguaje V8. La primera versión de Node.js expuso temporizadores y se ejecutó desde un archivo JavaScript, siguiendo la especificación ECMAScript.
Y luego mapeo a una función en C++. Cada función que tenemos en Node.js se instancia utilizando el mismo enfoque. Ahora, podemos ver qué es JavaScript. Así que una nueva fecha es JavaScript, aunque el tiempo depende del entorno, ¿verdad? Es la única excepción. Podemos usar plantillas de cadenas allí. También podríamos usar mapas. Podríamos usar operadores de propagación. Todo está integrado en V8. E incluso las promesas. Las promesas no son operaciones asíncronas. Son solo envoltorios para devoluciones de llamada que nos ayudan a los desarrolladores a escribir un código mejor, ¿de acuerdo? Bueno, intentemos hacer algo más interesante. ¿Qué tal setTimeout e setInterval? Recuerda la complejidad. Quiero programar una función que se ejecutará en el futuro, y esas variables y referencias deben estar allí cuando tenga que llamarlas de vuelta, y luego tengo que llamar de vuelta al lado de JavaScript, ¿de acuerdo? Esto me llevó un tiempo, amigo mío. Fue realmente loco construirlo. Pero echemos un vistazo al resultado final. Primero, voy a tener una clase. No prestes atención al lado de C++. Solo veamos los argumentos. Así que voy a tomar el tiempo de espera, el intervalo y asegurarme de que el tercer argumento sea una función de devolución de llamada. Luego voy a crear algo para almacenar esos valores, para que pueda ejecutarlos en el futuro. Y aquí estoy creando un temporizador en libuv. Así que inicio, simplemente envío y digo qué función se ejecutará al final. Y luego puedo ir a esta función y ver cuando el temporizador ha terminado, vuelve a C++, puedo obtener todo el contexto y luego puedo generar el resultado que voy a enviar de vuelta a JavaScript y llamar a nuestra función de devolución de llamada. Es una locura verlo, ¿verdad? No, para mí fue como magia con JavaScript, pero al final solo están simplificando toda la complejidad para que podamos comenzar a usar lo que ya sabemos. Y luego, si intentas ver el código UV, que es el while true que te dije, solo tenemos la ejecución y se asegura de que todos los eventos se despachen más tarde. Y seguimos la misma idea, compilamos el código y esperamos nuevos eventos. Y luego voy a establecer el tiempo de espera exactamente de la misma manera que hice para la impresión y otros. Ahora, lo que te dije de que las promesas son JavaScript y no operaciones LibuV o asíncronas. Puedo tomar la misma función que creé que usa una devolución de llamada, puedo hacer un envoltorio y usar async/await porque async/await es V8, ¿verdad? Es parte del lenguaje. Y una cosa interesante, si vas a la primera versión en la V0.1.1, así es como Ryan Doll hizo la primera versión de ella, ¿de acuerdo? Estaba exponiendo los temporizadores y ejecutándolos desde un archivo JavaScript y agregando más complementos en realidad. Así que debemos saber que V8, lo que JavaScript hace por defecto es
6. Introduction to Runtimes and Research
Short description:
Es por eso que tenemos módulos ECMAScript para reemplazar como el Common JS o el Required JS y facilitar nuestras vidas y también las vidas de los autores de otros runtimes. Bueno, ahora tenemos muchos otros nuevos runtimes que vienen, ¿verdad? La primera pregunta que tuve fue, ¿es fácil crear un runtime? ¿Por qué necesitamos un runtime ahora? Node ha estado allí durante casi 10 años. Así que comencé a investigar, a revisar su código y tenía algunas suposiciones. Primero, DNO. Si vas al código fuente de DNO, verás un código muy similar al que tenemos en el lado de C++ escrito en Rust. Está tomando una cadena, compilándola y ejecutándola. ¿De acuerdo? La misma idea. Exactamente la misma idea en C++. Y luego puedes ver que está inyectando DNO core, que extiende V8 e inyecta más código. Exactamente la misma idea interesante. ¿Qué pasa con Bunn? Bueno, Bunn es más una idea de ciencia matemática porque utiliza JavaScript core en lugar de V8, que no tiene documentación. No sé cómo lo ha escrito, y está escrito en Zig. Pero al mirar todo el código, verás el mismo enfoque. Está extendiendo las vinculaciones naturales del runtime de JavaScript y ejecutando muchas cosas.
conocido por la especificación ECMAScript. Es por eso que tenemos módulos ECMAScript para reemplazar como el common JS o el required JS y facilitar nuestras vidas y también las vidas de los autores de otros runtimes. Bueno, ahora tenemos muchos otros nuevos runtimes que vienen, ¿verdad? La primera pregunta que tuve fue, ¿es fácil crear un runtime? ¿Por qué necesitamos un runtime ahora? Node ha estado allí durante casi 10 años. Así que comencé a investigar, a revisar su código y tenía algunas suposiciones. Primero, DNO. Si vas al código fuente de DNO, verás un código muy similar al que tenemos en el lado de C++ escrito en Rust. Está tomando una cadena, compilándola y ejecutándola. ¿De acuerdo? La misma idea. Exactamente la misma idea en C++. Y luego puedes ver que está inyectando DNO core, que extiende V8 e inyecta más código. Exactamente la misma idea interesante. ¿Qué pasa con Bunn? Bueno, Bunn es más una idea de ciencia matemática porque utiliza JavaScript core en lugar de V8, que no tiene documentación. No sé cómo lo ha escrito, y está escrito en Zig. Pero al mirar todo el código, verás el mismo enfoque. Está extendiendo las vinculaciones naturales del
7. JavaScript Runtimes and Collaboration
Short description:
Lo que hace que un tiempo de ejecución de JavaScript sea mejor que otros es cómo manejan la complejidad de los módulos y la comunicación entre procesos. Bunn afirma ser más rápido debido a mejores algoritmos. La experiencia del desarrollador también juega un papel importante, con Dino ofreciendo características como pruebas nativas y TypeScript. Sin embargo, no es una competencia entre Dino, Bunn y Node.js. Están colaborando y compartiendo ideas para beneficiar a los desarrolladores. Si quieres aprender más e implementar tu propio FS, hay un tutorial en video y un libro electrónico disponibles en el sitio web del ponente.
Tiempo de ejecución de JavaScript y ejecutando muchas cosas. Entonces, desde atrás, es posible que te estés preguntando en este momento. Bueno, tenemos muchos, ¿verdad? CloudFlare workers, Dino y otras cosas. ¿Qué hace que uno sea mejor que otros? Esto era algo que me preguntaba, ¿cómo son más rápidos o cuál es el punto de crear un nuevo tiempo de ejecución de JavaScript? Bueno, el punto es, recuerda que C++ es el puente. Entonces, allí, en Node.js, tenemos todos los módulos. Esta es la impresión para Fs y lo que hace que un tiempo de ejecución sea mejor que otros es cómo manejan toda esta complejidad. Así que estoy recibiendo resultados del sistema operativo y estoy tratando de hacer ping a todos los servicios llamando a procesos, yendo y viniendo con las cadenas y podemos ver cómo están haciendo estos enfoques. Entonces, Bunn afirma ser más rápido porque utiliza mejores algoritmos para escribir y ejecutar funciones. Bonito, ¿verdad? En mi opinión, lo que hace que uno sea mejor que otros es la experiencia del desarrollador. Dino ha venido con, como, una prueba nativa. Tienen TypeScript y muchas cosas más para ayudar a los desarrolladores a escribir código más rápido y en mi opinión, esto importa mucho. ¿Pero es una competencia? ¿Dino reemplazará a Node? ¿Bunn reemplazará a Node o Dino? En mi opinión, van a colaborar entre sí. Entonces, Jarrett Sommer, quien también está hablando en esta conferencia, se unió a la organización de Node.js. Además, Colin Rigg, quien solía trabajar en Dino, ha estado trabajando en Node.js desde el principio. Entonces, todos están colaborando juntos para que podamos beneficiarnos. Y también hay un grupo de trabajo para que puedan compartir ideas. En el mundo de los tiempos de ejecución de JS, no tenemos ECMAScript, ¿verdad? Cualquiera podría escribir funciones C++ como desee. Así es como lo harían. Bonito, ¿verdad? Voy a ver, oh. Si quieres profundizar más e intentar implementar tu propio FS, te recomiendo encarecidamente el video. Allí, paso casi dos horas construyendo este tutorial para que incluso puedas complementarlo, ¿de acuerdo? Todo el contenido que te he enseñado, todas las ideas, todas las charlas ya están en mi sitio web. Entonces, si quieres ir más allá, estudiar más, puedes ir allí. Y de hecho, también publiqué un libro electrónico sobre toda esta charla.
QnA
Closing Remarks and Q&A
Short description:
Antes de terminar esta charla, tomemos una selfie y hagamos algo de ruido. Gracias por tenerme aquí. Estaré en el escenario con Ryan Dow para más discusiones. Ahora, respondamos una pregunta sobre por qué el proyecto de demostración se llama Capybara. Quería mostrar que Brasil es más que solo samba. Una de las cosas que más me gusta de mi trabajo es el poder de la comunidad y la curiosidad. He tenido conversaciones con personas de Google y V8, y ahora estoy planeando recrear React Native. Es una tarea desafiante, pero divertida. Hablando de desafíos, encontrar el coraje para hacer esto viene de mi amor por la historia. Incluso las mentes más grandes enfrentan problemas similares. Así que acepto el desafío.
puedes ir paso a paso. Antes de terminar esta charla, nos queda un minuto. Así que tenemos una tradición de tomarnos una selfie y molestar a los demás en el otro escenario, ¿de acuerdo? Así que voy a contar hasta tres y voy a hacer algo de ruido, ¿de acuerdo? Muy bien. Oh, genial. Entonces empecemos. Uno, dos, tres. ¡Ahh! Muchas gracias por tenerme aquí. También estaré en el escenario donde está Ryan Dow ahora mismo para discutir más si quieren reunirse y hacer preguntas y sugerencias sería genial. Bueno, gracias. Por favor, únanse a mí. Solo tenemos una pregunta, así que por favor traigan su pregunta a la diapositiva. Y la pregunta es, ¿por qué el proyecto de demostración se llama Capybara? Bueno, nosotros los brasileños tendemos a mostrar al mundo que no somos solo samba, ¿verdad? Entonces, el capibara es un animal muy conocido allí, parece un cerdo muy grande. Y realmente me encanta llamarlo capibara por eso, para tener algunas referencias, ¿verdad? Genial. ¿Cuál es una cosa favorita que puedes compartir sobre tu trabajo? Bueno, yo diría como Anna, ella está allí. Esta chica me ayudó mucho. Y esto es, diría, el poder de la comunidad y en realidad parte de ser curioso, ¿verdad? Hacía muchas preguntas y ella me decía, vamos, ¿por qué, qué quieres hacer? ¿Por qué quieres recrear algo? Yo decía, quiero aprender. Muy bien. Así que empecé a hacer muchas preguntas a la gente y ellos decían, no tengo idea. Tuve algunas conversaciones con personas en Google, en V8. Ellos decían que solo trabajaban con algo que funcionaba allí, el entorno funcionaba, pero nunca pensaron en recrear todo el asunto. Así que ahora, mi próximo paso es aún más difícil, pero tengo algunas ideas. Voy a intentar recrear el React Native. Así que quiero usar cosas como Alert y ver el Toaster en iOS y un Toaster en Android. Pero el problema es que tenemos que compilar todo el asunto, ¿verdad? Así que el entorno es realmente, realmente difícil de manejar, pero es divertido. La siguiente pregunta es, ¿cómo encuentras el coraje para hacer esto? ¿Con qué código te diviertes más? ¿El de Dino o el de Node? Bueno, me gusta la historia, ¿verdad? Yo diría que por eso amo Berlín. La gente, todo es tan histórico. Y estaba revisando, como produzco contenido a diario y estaba mirando las marcas, las más antiguas, y si vas allí, lo disfrutarás mucho. Como Ryan Dahl, esto está funcionando desde el comité y luego esto ya no funciona. Como, a veces encontramos a esos héroes y a veces pensamos, no, tal vez estas personas son genios y así sucesivamente. Pero a veces tienen los mismos problemas que enfrentamos, ¿verdad? Sí.
Explorando Experimentos Personales e Historias de YouTube
Short description:
Diría que porque no había contenido en Internet. ¿Has considerado escribir tu propio bucle de eventos para un tiempo de ejecución de juguete como este en lugar de libuv? Bueno, nunca. En realidad, libuv fue escrito para Node.js, ¿verdad? ¿Cuál es la recreación de la que estás más orgulloso? Es difícil de decir. Estaba intentando usar aprendizaje automático en el navegador utilizando las APIs de TensorFlow. ¿Alguna financiación o descubrimientos de Node.js, brepro, arqueología? Oh, no tengo idea. ¿Habrá algún video sobre cómo crear tu propia imagen de Node-Docker como Alpine, etc., por favor? ¿Cuánto dinero ganas en YouTube? No estás escuchando, ¿verdad? No. Permíteme contar una historia. YouTube es horrible.
Entonces, diría que, en general, me puse este desafío. Diría que porque no había contenido en Internet. Así que, si me pongo en esto, tal vez otras personas también puedan beneficiarse y podamos ayudar a nuestro ecosistema. Genial. ¿Has considerado escribir tu propio bucle de eventos para un tiempo de ejecución de juguete como este en lugar de libuv?
Bueno, nunca. En realidad, libuv fue escrito para Node.js, ¿verdad? Antes era, creo, libio que solo funcionaba en sistemas operativos Linux y Mac, y libuv vino a ayudar en el sistema Mac. Pero estaba mirando las APIs del sistema operativo, Dios mío, esto no es legible para los humanos, ¿verdad? No sé si hay algún desarrollador de C++ aquí. Realmente valoro mucho tu trabajo, porque es bastante difícil. Sí, parece. ¿Cuál es la recreación de la que estás más orgulloso? Es difícil de decir. Diría que siempre intento enseñar algo que no estoy 100% seguro de saber, para desafiarme mucho. Lo último fue, diría, estaba intentando usar aprendizaje automático en el navegador utilizando las APIs de TensorFlow. Y pensé, ¿qué tal si puedo usar la cámara web para hacer clic en los elementos como lo hacía la realidad virtual, ¿verdad? Así que la API era increíble haciendo esto, así que tuve que mapearlo todo. Pero el navegador no te permite simular un hover. Así que fue un desafío encontrar el CSS del elemento para poder hacer clic, pero fue muy divertido. Y solo por curiosidad, después de dos semanas, Zuckenberg publicó, como, chicos, oh, Zuckenberg te está robando. Vamos, dale un aumento, hombre. ¿Qué? Lo siento. ¿Alguna financiación o descubrimientos de Node.js, brepro, arqueología? Oh, no tengo idea, pero tal vez lo del Atlántico, ¿verdad? No sé si es así. No tengo idea. Sí. No sé si se puede llamar arqueología, pero está ahí, ¿verdad?, las ramas y todas esas cosas, cosas antiguas. ¿Habrá algún video sobre cómo crear tu propia imagen de Node-Docker como Alpine, etc., por favor? Bueno. Quiero decir, no lo sé, hay tantos buenos ahora mismo instalando todos los paquetes. No estoy seguro si agregaría más valor creando esto, pero no estoy seguro. Wow. ¿Cuánto dinero ganas en YouTube? No estás escuchando, ¿verdad? No. Permíteme contar una historia. YouTube es horrible. Así que tienes gente para
Producción de Contenido y Runtimes
Short description:
Al final, estoy pagando por hacer estas cosas porque produzco mucho contenido. No tenía idea de que console.log no es Javascript. Señor da so es una jerga en portugués para referirse a un nivel alto. El mejor runtime para microservicios depende de la experiencia del desarrollador y la preferencia del equipo. El prefijo WTF en el código GSA probablemente sea una plantilla utilizada en C++ para enlazar bibliotecas y referirse a funciones en tiempo de ejecución.
editar tu video, crear una buena miniatura, que la gente lo edite o lo revise. Al final, estoy pagando por hacer estas cosas. Sin embargo, no es solo eso, ¿verdad? Es porque estoy produciendo mucho contenido. Puedo hacer un producto de calidad o algo premium para que la gente obtenga valor, cambiar de trabajo mucho y así es como sobrevivo en la actualidad, ¿verdad? Esto no es una pregunta, pero no tenía idea de que Saitama o console no formaban parte de ES. Así que estaba como evangelista. Le estaba hablando a mi mamá. Mamá, ¿sabías que console.log no es Javascript? Fue una locura porque lo he visto desde el principio. Es lo primero que hacemos en Javascript y en realidad, no es Javascript. Es una locura, ¿verdad? Dice Señor da so en la mente. Supongo que, no sé qué es eso. ¿Es portugués? No tengo idea. Señor da so. Esto tiene algo que ver con el inglés, ¿verdad? Porque en portugués tenemos muchas jergas y cuando vamos al inglés, no podemos usarlas todas. Así que Señor da so es como senior, nivel alto. Lo usamos mucho. Es realmente agradable.
De acuerdo, esta es una charla increíble. En tu opinión, ¿cuál es uno de los mejores runtimes para microservicios en este momento? Oh, quieres ponerme en aprietos, ¿verdad? Oh, dios mío, es difícil de decir, ¿verdad? Diría que no, no lo sé, es difícil porque he visto cómo BAN está evolucionando mucho y cómo Node.js es tan maduro, cómo Dino, ha sido bueno. Diría que lo mejor es lo que mejora tu experiencia porque en términos de rendimiento, hemos visto algunas pruebas de referencia que muestran, oh, esto es más rápido, pero el 90% de las aplicaciones son aplicaciones CRUD, ¿verdad? Así que es difícil sentir toda esta mejora y en mi opinión, lo mejor es la mejor experiencia de desarrollo y lo que más le gusta a tu equipo. Diría que es más una opinión personal que para los runtimes. Pero esa es mi opinión, ¿verdad? Tengo más experiencia con Node que con otros runtimes también. La gente puede pensar de manera diferente, ¿verdad? Definitivamente. Tenemos una pregunta más. ¿Qué significa el prefijo WTF en el código GSA que vimos? Por ejemplo, incluye WTF/slash/model.h. Bueno, diría que WTF es un texto muy específico, ¿verdad? Voy a pensar que es una plantilla. Entonces, en C++, usamos include para enlazar las bibliotecas y decir, oh, voy a llamar a esta función, por ejemplo, la compilación de V8. Cuando uso V8 compile, tengo que incluir los encabezados. Entonces, cuando está en tiempo de ejecución, se va a referir al binario, ¿verdad? Si miras todo el pod de puerta que construí, V8 tiene dos gigabytes. Así que esto es algo de lo que estaba hablando con Anna, cómo dos gigabytes se convierten en 200 gigabytes al final de Node.js. Esto es realmente interesante. Estaba como, oh dios mío,
Choosing Node.js and Inspiration
Short description:
Elegí Node.js porque me sentía limitado como desarrollador de .NET y quería liberarme de estar atado a herramientas específicas. Con Node.js, pude aprender el funcionamiento interno y tener la capacidad de solucionar o comprender cualquier problema que surja. ¡Gracias por la charla informativa y atractiva!
Cuéntame todo. Y ahora es la última pregunta. ¿Por qué elegiste Node.js? ¿Cuál es tu inspiración? Elegí Node.js. Solía ser un desarrollador de .NET. Y en ese entonces, no diría que el lenguaje fuera un problema, pero sentía que estaba en una jaula. Recuerdo estar trabajando, y tenía alguna actualización en mi Visual Studio, y no podía trabajar. Pensaba, venga. Estoy atado a alguna herramienta. No soy un verdadero desarrollador, pensaba. Con Node.js, cuando llegó, estaba usando Sublime o Notepad en una terminal. Así que para mí fue como, esto es lo que voy a aprender, la verdadera cosa en Node.js o aprender cómo funciona detrás de escena. Porque si el framework deja de funcionar o la biblioteca o algo en sí mismo, podría solucionarlo yo mismo, ¿verdad? O al menos entenderlo. Genial, muchas gracias por tu charla y por responder todas las preguntas. Fue una gran charla. Gracias. ¡Gracias! ¡Dame un diez!
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.
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
BUN is a modern all-in-one JavaScript runtime environment that achieves new levels of performance. It includes BUN dev, a fast front-end dev server, BUN install, a speedy package manager, and BUN run, a fast package runner. BUN supports JSX, has optimized React server-side rendering, and offers hot module reloading on the server. The priorities for BUN include stability, node compatibility, documentation improvement, missing features in BUN install, AST plugin API, native Windows support, Bundler and Minifier optimization, and easier deployment to production. BUN's AST plugin API allows for bundle-time JavaScript execution and embedding code, potentially inspiring new frameworks.
This talk covers various techniques for getting diagnostics information out of Node.js, including debugging with environment variables, handling warnings and deprecations, tracing uncaught exceptions and process exit, using the v8 inspector and dev tools, and generating diagnostic reports. The speaker also mentions areas for improvement in Node.js diagnostics and provides resources for learning and contributing. Additionally, the responsibilities of the Technical Steering Committee in the TS community are discussed.
Deno aims to provide Node.js compatibility to make migration smoother and easier. While Deno can run apps and libraries offered for Node.js, not all are supported yet. There are trade-offs to consider, such as incompatible APIs and a less ideal developer experience. Deno is working on improving compatibility and the transition process. Efforts include porting Node.js modules, exploring a superset approach, and transparent package installation from npm.
¿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.
Platformatic te permite desarrollar rápidamente APIs GraphQL y REST con un esfuerzo mínimo. La mejor parte es que también te permite aprovechar todo el potencial de Node.js y Fastify cuando lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y complementos adicionales. En el masterclass, cubriremos tanto nuestros módulos de código abierto como nuestra oferta en la nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). En este masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la nube de Platformatic.
Construyendo un Servidor Web Hiper Rápido con Deno
WorkshopFree
2 authors
Deno 1.9 introdujo una nueva API de servidor web que aprovecha Hyper, una implementación rápida y correcta de HTTP para Rust. El uso de esta API en lugar de la implementación std/http aumenta el rendimiento y proporciona soporte para HTTP2. En este masterclass, aprende cómo crear un servidor web utilizando Hyper en el fondo y mejorar el rendimiento de tus aplicaciones web.
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada. Mejoraremos una aplicación JS de pila completa (backend de Node.JS + frontend de React) para autenticar usuarios con OAuth (inicio de sesión social) y contraseñas de un solo uso (correo electrónico), incluyendo:- Autenticación de usuario - Administrar interacciones de usuario, devolver JWT de sesión / actualización- Gestión y validación de sesiones - Almacenar la sesión para solicitudes de cliente posteriores, validar / actualizar sesiones Al final del masterclass, también tocaremos otro enfoque para la autenticación de código utilizando Flujos Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña. Tabla de contenidos- Una breve introducción a los conceptos básicos de autenticación- Codificación- Por qué importa la autenticación sin contraseña Requisitos previos- IDE de tu elección- Node 18 o superior
Aprende cómo construir rápidamente aplicaciones peer-to-peer con Pear Runtime. No se requieren servidores. Comprende los paradigmas peer-to-peer y construye aplicaciones a partir de bloques de construcción bien definidos. En este masterclass se cubrirá cómo crear aplicaciones de escritorio y terminales (con discusión para móviles) que funcionan completamente peer-to-peer desde cualquier lugar del mundo. Al final de este masterclass, deberías saber cómo construir un nuevo tipo de aplicación altamente escalable con costos infraestructurales reducidos (~0) junto con arquitecturas adecuadas y mejores prácticas para aplicaciones peer-to-peer. Del creador de Pear Runtime y la compañía que nos trae keet.io. Tabla de contenido:- Introducción a Pear- Preguntas y respuestas iniciales- Configuración- Creación de una aplicación de escritorio Pear- Compartir una aplicación Pear- Ejecutar una aplicación Pear- Creación de una aplicación terminal Pear- Lanzamiento de una aplicación Pear- Discusiones arquitecturales- Preguntas y respuestas finales
Node.js test runner es moderno, rápido y no requiere bibliotecas adicionales, pero entenderlo y usarlo bien puede ser complicado. Aprenderás a utilizar Node.js test runner a su máximo potencial. Te mostraremos cómo se compara con otras herramientas, cómo configurarlo y cómo ejecutar tus pruebas de manera efectiva. Durante la masterclass, haremos ejercicios para ayudarte a sentirte cómodo con el filtrado, el uso de afirmaciones nativas, la ejecución de pruebas en paralelo, el uso de CLI y más. También hablaremos sobre trabajar con TypeScript, hacer informes personalizados y la cobertura de código.
Comments