Video Summary and Transcription
Hola, soy Annembae, el autor de MillionJS, un reemplazo rápido del DOM virtual para React. El DOM virtual puede ser lento dependiendo de los componentes que alimenta. El DOM virtual de bloque introduce una optimización O(1) al DOM virtual tradicional, lo que resulta en actualizaciones más rápidas con menos manipulaciones del DOM. MillionJS y el DOM Virtual de Bloque ofrecen una alternativa más rápida a las bibliotecas existentes de dom-virtual como React. Tiene el potencial de revolucionar la forma en que escribimos aplicaciones React.
1. Introducción al DOM Virtual
Hola, soy Annembae, el autor de MillionJS, un rápido reemplazo del DOM virtual para React. El DOM virtual ha sido criticado como un puro exceso, pero ahora es el momento de reconsiderarlo. El DOM virtual puede ser lento dependiendo de los componentes que alimenta. Funciona representando la interfaz de usuario como un árbol y actualizándola con un algoritmo de diferencias.
Hola, mi nombre es Annembae. Soy el autor y creador de MillionJS, un rápido reemplazo del DOM virtual para React. También soy estudiante de CS en la Universidad de Washington. De hecho, este es mi dormitorio aquí. Así que hoy les hablaré sobre el DOM virtual, pero esta vez, de vuelta en bloque.
Hace poco más de cuatro años, Rich Harris publicó El DOM Virtual es Puro Exceso. Rich dijo notablemente, probablemente has escuchado la frase, el DOM virtual es rápido, a menudo queriendo decir que es más rápido que el DOM real. De hecho, es un meme sorprendentemente resistente. En este artículo, Rich Harris argumenta que el DOM virtual, una característica ampliamente elogiada de frameworks como React, no es tan eficiente como muchos de nosotros creemos. Continúa criticando la forma en que funciona y presenta Svelte. Pero lo que siguió años después fue la aparición de un nuevo meme, que el DOM virtual es puro exceso. El meme se volvió tan resistente que transformó el movimiento del framework sin DOM virtual de un subgrupo iconoclasta a una cruzada completamente desarrollada. Así, el DOM virtual fue relegado al estatus de primo molesto que nadie le gusta pero tiene que invitar a las reuniones familiares. Se convirtió en un mal necesario, un impuesto al rendimiento que teníamos que pagar por la comodidad de las UIs declarativas. Hasta ahora.
Entonces, la pregunta natural que todos o ustedes probablemente están haciendo es ¿por qué el DOM virtual es lento? Pero creo que una mejor pregunta sería ¿cuándo puede ser lento el DOM virtual? Y todo es por culpa de este tipo. Probablemente hayas escuchado su música video. En realidad no me refiero a este tipo, sino al componente que lo alimenta. Echemos un vistazo. Una rama es un código de retorno a menos que seas AngularJS. Si math.random es superior a .5. También puede devolver, ya sabes, el gif de rick rule. Así que puedes ver aquí naturalmente que podría haber una actualización entre la regla de rick y el AngularJS. ¿Cómo funciona esto? Bueno, ahí es donde entra el DOM virtual. Entonces, el DOM virtual es esencialmente un árbol o representación de datos de la interfaz de usuario, o en este caso el DOM. Puedes ver aquí que hay cinco nodos en el viejo árbol del DOM virtual, y hay tres nodos en el nuevo. ¿Cómo actualizamos la interfaz de usuario basándonos en estos árboles? Bueno, ejecutamos un dif. Así que recorremos ambos árboles a la vez. Primero, comprobamos el primer nodo. ¿Ha cambiado el primer nodo? No lo creo.
2. Introducción a la Optimización del DOM Virtual
¿Y el segundo? Dos ha cambiado a cinco. Podemos hacer una actualización del DOM. Si comprobamos el tercero, el tercer nodo ha sido eliminado. El DOM virtual es realmente agradable porque puede procesar todos los nodos y hacer la cantidad mínima de actualizaciones del DOM. Pero cuando tienes más nodos, se vuelve ineficiente. Así que hoy voy a presentar un nuevo enfoque para hacer el DOM virtual diferenciando los datos en lugar del DOM.
¿Y el segundo? Sí. Dos ha cambiado a cinco. Y lo que podemos hacer aquí es hacer una actualización del DOM. Es como hacer un intertexto de punto o reemplazar un nodo o lo que sea.
Sigamos. Si comprobamos el tercero, podemos ver que el tercer nodo ha sido eliminado. Y entonces podemos eliminarlo en el DOM. Y así sucesivamente. Puedes ver aquí que el DOM virtual es realmente agradable porque no importa cómo sea la forma de su interfaz de usuario. No importa cuántos nodos tengamos. Eventualmente podemos procesar todos ellos y hacer la cantidad mínima de actualizaciones del DOM en la página. Entonces, esto es genial, ¿verdad? Esencialmente, puedes cambiar las antiguas interfaces de usuario a las nuevas utilizando esta estructura de árbol virtual.
Pero, ¿qué pasa cuando tienes más nodos? Uh oh, estás haciendo cinco diferencias. Es agradable cuando tienes cinco diferencias porque vas a tener que cambiar cinco nodos de todos modos. Pero, ¿qué pasa cuando solo cambias un nodo? Bueno, todavía tienes que hacer cinco diferencias aquí, ¿verdad? Tienes que comprobar si foo es el mismo. Y en este caso, solo actualizas uno. Así que esto puede volverse realmente ineficiente. Así que imagínalo como O de n. A medida que tu interfaz de usuario se hace más grande, cuanto más tienes que diferenciar, más lenta se vuelve tu aplicación. Y aquí tienes una visualización de eso. Una vez que tienes 200 nodos en tu página, se vuelve realmente lento.
Así que hoy voy a presentar algo nuevo. Un nuevo enfoque para hacer el DOM virtual. En lugar de diferenciar las estructuras de árbol y hacer todas estas cosas, ¿qué tal si solo diferenciamos los data y no el DOM? Bueno, todo esto comienza con un compilador. El compilador puede mirar el DOM virtual con antelación. Así que todavía tenemos esta estructura de árbol aquí, solo que no está en el runtime. Así que aquí conocemos la relación entre los data y la interfaz de usuario aquí. Así que puedes imaginar en React, tienes un estado de uso con un conteo o lo que sea. Esto podría ser un conteo o esto podría ser un nodo en nuestro caso. No necesariamente conocemos los valores de antemano, así que ponemos un nodo de marcador de posición dentro de estos.
3. Introducción al Block Virtual DOM
Esencialmente, el Block Virtual DOM introduce una optimización O(1) al tradicional Virtual DOM. Crea un mapeo relacional entre los datos y la interfaz de usuario, resultando en actualizaciones más rápidas con menos manipulaciones del DOM. MillionGS, un reemplazo directo para React, implementa el Block Virtual DOM y supera tanto a React como a Preact en benchmarks sintéticos. Un ejemplo demuestra el mejor rendimiento, con MillionGS proporcionando una experiencia de usuario más fluida en comparación con React.
Así que esencialmente tenemos este árbol y los valores dinámicos que se colocan en los nodos están marcados como potencialmente, como que potencialmente podría haber un valor allí. Y entonces lo que hacemos ahora es simplemente recorrer el árbol como es habitual. Comprobamos el primero como un marcador de posición, y así sucesivamente, y cuando encontramos un marcador de posición, podemos crear algo llamado un mapa de edición. Esta es la salsa secreta del Block Virtual DOM.
Esencialmente lo que decimos es que cuando el nodo 1 cambia o estos data cambian, cambiamos este nodo. Esencialmente tenemos este mapeo relacional entre los data y la interfaz de usuario. Y podemos hacer esto para cada nodo marcador de posición en el árbol. Y durante el runtime, el mapa de edición realmente, realmente brilla. Puedes ver aquí cuando estamos tratando de actualizar el valor del nodo 1 y el nodo 2 a 3 y 4, respectivamente, puedes ver que sólo tenemos que hacer dos divs. Así que comprobamos si los data son los mismos, 1, 3, sí, ha cambiado. Lo comprobamos de nuevo, ha cambiado. Y podemos hacer actualizaciones al DOM virtual. Te das cuenta aquí de que el DOM virtual tomaría 5 divs, pero con el Block Virtual DOM, sólo toma 2. Y esto escala infinitamente. Esto es esencialmente una optimización O de 1 al DOM virtual.
Y esto es realmente genial, porque tenemos el mismo ejemplo de 200 nodos en la página. Ahora puedes ver que el cambio es O de 1. Cada vez que actualizas, hay un cambio O de 1. Y es realmente, realmente rápido. Así que trabajo en un proyecto llamado MillionGS. Y esto implementa el Block Virtual DOM como un reemplazo directo para React. Usando eso, es un 30% más rápido que Preact, que es una alternativa ligera a React, y más de un 70% más rápido que React en benchmarks sintéticos. Y así esto es realmente, realmente indicativo de un mejor performance usando el Block Virtual DOM, particularmente en benchmarks, en comparación con las alternativas tradicionales del DOM virtual. Así que esencialmente, MillionGS y el Block v DOM son más rápidos que React. Y si no me crees, puedes echar un vistazo a este ejemplo. Tengo una computadora realmente mala, así que ten paciencia. Cuando hago clic en este botón, es realmente, realmente rojo, y eso es indicativo de un mal performance. Pero cuando cambio a Million, cuando se carga, si no me da la bola de playa, puedes ver que cuando hago clic aquí, es mucho mejor. Antes era simplemente un rojo puro. Era un círculo rojo como sangre.
4. Ventajas de MillionJS y Block Virtual DOM
MillionJS y el Block Virtual DOM ofrecen una alternativa más rápida a las bibliotecas existentes de virtual-dom como React. Tiene el potencial de revolucionar la forma en que escribimos aplicaciones de React, proporcionando un rendimiento mejorado sin las consecuencias asociadas. Sígueme en Twitter en AidenYBi o visita Million.dev para aprender más.
Pero ahora está en los verdes y los amarillos. Million es mucho mejor para renderizar muchas aplicaciones pesadas en data y en interfaz de usuario.
Muchas gracias por escuchar. Esta es solo una breve charla relámpago de mi trabajo en MillionJS y el Block Virtual DOM. Hay mucha investigación por hacer en este campo. El Block Virtual DOM fue introducido originalmente hace quizás dos años por un proyecto llamado BlockDOM. Hay mucho más por descubrir, investigar e introducir. Al igual que Signals, el Block Dom es una solución potencial para las bibliotecas existentes de virtual-dom, como React en particular. Esta es mi misión con Million.dev. ¿Y si fuéramos capaces de escribir nuestras aplicaciones de React con este DOM virtual más rápido y no tener que pagar ninguna de las consecuencias por ello?
Si estás interesado, sígueme en Twitter en AidenYBi o echa un vistazo a mi proyecto, Million.dev, en la web. Muchas gracias por escuchar. Que tengas un gran día.
Comments