1. Introducción al DOM virtual
Hola, mi nombre es Anand Bai. Voy a hablar sobre el DOM virtual y su rendimiento. Rich Harris argumentó que el DOM virtual no es tan eficiente como muchos creen, lo que llevó a la aparición del meme de que es un puro exceso. ¿Pero cuándo puede ser lento el DOM virtual? Todo se debe al componente que lo alimenta. Echemos un vistazo a cómo funciona.
Hola, mi nombre es Anand Bai. Soy el autor y creador de Millionjs, un rápido reemplazo del DOM virtual para React. También soy estudiante en la Universidad de Washington para CS. De hecho, este es mi dormitorio aquí mismo. Así que hoy, voy a hablarles sobre el DOM virtual, pero esta vez, de vuelta en bloque.
Hace poco más de 4 años, Rich Harris lanzó Virtual DOM es puro exceso. Rich dijo notablemente, probablemente has escuchado la frase, el DOM virtual es rápido, a menudo se dice que es más rápido que el DOM real. De hecho, es un meme sorprendentemente resistente. En su 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 marco sin DOM virtual de un subgrupo iconoclasta a una cruzada completamente desarrollada. Así, el DOM virtual fue relegado al estado de primo molesto al 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 interfaces de usuario declarativas... hasta ahora.
Entonces, la pregunta natural que todos, o ustedes, probablemente se están haciendo es... ¿Por qué es lento el DOM virtual? Pero creo que una mejor pregunta sería... ¿Cuándo puede ser lento el DOM virtual? Y todo se debe a 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 0.5. También puede devolver un GIF de regla RIC. Así que puedes ver aquí naturalmente que podría haber una actualización entre la regla RIC y el AngularJS. ¿Cómo funciona esto? Bueno, aquí 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 antiguo árbol del DOM virtual. Y hay tres nodos en el nuevo. Entonces, ¿cómo actualizamos la interfaz de usuario en base a estos árboles? Bueno, ejecutamos una diferencia. Así que recorremos ambos árboles a la vez.
2. Introducción al DOM Virtual (Parte 2)
Primero revisamos el primer nodo. ¿Ha cambiado el primer nodo? ¿Y el segundo? Sí, el dos ha cambiado a cinco. Si revisamos el tercero, podemos ver que el tercer nodo ha sido eliminado. El DOM virtual es realmente agradable porque no importa cómo se vea la forma de su interfaz de usuario. Pero, ¿qué sucede cuando tienes más nodos? Hoy, voy a presentar algo nuevo, un nuevo enfoque para hacer el DOM virtual.
Primero revisamos el primer nodo. ¿Ha cambiado el primer nodo? No lo creo. ¿Y el segundo? Sí, el dos ha cambiado a cinco. Entonces, lo que podemos hacer aquí es una actualización del DOM. Es como hacer .innertext o reemplazar un nodo o lo que sea. Sigamos.
Si revisamos 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 se vea 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. Así que esto es genial. Esencialmente, puedes cambiar las antiguas interfaces de usuario a nuevas interfaces de usuario utilizando esta estructura de árbol virtual.
Pero, ¿qué sucede cuando tienes más nodos? Estás haciendo cinco diferencias. Es agradable cuando tienes cinco diferencias porque vas a tener que cambiar cinco nodos de todos modos. Pero, ¿qué sucede cuando solo cambias un nodo? Bueno, todavía tienes que hacer cinco diferencias aquí. Tienes que comprobar si foo es el mismo. Y en este caso, solo actualizas uno. Así que esto puede ser realmente ineficiente. Así que imagínalo como O de n. A medida que tu interfaz de usuario se hace más grande, más tienes que diferenciar, y 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 anticipació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 que tienes un use state con un count y lo que sea.
3. Optimizando Actualizaciones con Mapas de Edición
Esto podría ser un conteo o un nodo. Colocamos un nodo de marcador de posición en el árbol para valores dinámicos. Al recorrer el árbol, creamos un mapa de edición para cada nodo de marcador de posición. El mapa de edición optimiza las actualizaciones al DOM virtual, resultando en cambios O(1). MillionJS, un reemplazo directo para React, es significativamente más rápido que Preact y React en las pruebas de rendimiento.
Esto podría ser un conteo, o en nuestro caso, puede ser un nodo. No necesariamente conocemos los valores de antemano, por lo que colocamos un nodo de marcador de posición dentro de estos. Así que esencialmente, tenemos este árbol, y los valores dinámicos que se colocan en los nodos están marcados como posiblemente podría haber un valor allí.
Y lo que hacemos ahora es simplemente recorrer el árbol como de costumbre. Verificamos 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 DOM virtual de bloque. Esencialmente, lo que decimos es que cuando el nodo 1 cambia o este data cambia, cambiamos este nodo. Esencialmente, tenemos este mapeo relacional entre los data y la UI. Y podemos hacer esto para cada nodo de marcador de posición en el árbol.
Y durante el runtime, el mapa de edición realmente brilla. Puedes ver aquí cuando estamos intentando actualizar el valor del nodo 1 y el nodo 2 a 3 y 4, respectivamente, puedes ver que solo tenemos que hacer dos diferencias. Así que verificamos si los data son los mismos, 1, 3, sí, ha cambiado. Lo verificamos de nuevo, ha cambiado. Y podemos hacer actualizaciones al DOM virtual. Notarás aquí que el DOM virtual tomaría cinco diferencias, pero con el DOM virtual de bloque, solo toma dos. Y esto se escala infinitamente. Esto es esencialmente una optimization 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 MillionJS. Implementa el DOM virtual de bloque como un reemplazo directo para React. Usándolo, es un 30% más rápido que Preact, que es una alternativa ligera a React, y más del 70% más rápido que React en pruebas de rendimiento sintéticas. Y esto es realmente, realmente indicativo de un mejor performance usando el DOM virtual de bloque, particularmente en pruebas de rendimiento comparadas con alternativas tradicionales del DOM virtual. Así que esencialmente, MillionJS y el V DOM de bloque son más rápidos que React. Y si no me crees, puedes tomar 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.
4. Million.js y el DOM Virtual de Bloque
Antes, Million.js es mejor en la renderización de aplicaciones pesadas en datos y en UI. El DOM virtual de bloque, introducido por Block DOM, es una potencial solución a las bibliotecas existentes de DOM virtual como React. Million.dev tiene como objetivo permitir escribir aplicaciones de React con un DOM virtual más rápido sin ninguna consecuencia. Sígueme en Twitter en idynyy o visita million.dev.
Antes, era simplemente un rojo plano. Era un círculo rojo sangre, pero ahora está en los verdes y los amarillos. Y así Million es mucho mejor en la renderización de muchas y muchas aplicaciones pesadas en data y en UI.
Muchas gracias por escuchar. Esta es solo una breve charla relámpago de mi trabajo en Million.js y el DOM virtual de bloque. Hay mucha investigación por hacer en este campo. El DOM virtual de bloque fue originalmente introducido quizás hace dos años por un proyecto llamado Block DOM. Hay mucho más por descubrir, investigar e introducir. Al igual que las señales, el DOM virtual de bloque es una solución potencial a las bibliotecas existentes de DOM virtual, como React particularmente. Y esta es mi misión con Million.dev. ¿Qué pasaría si pudiéramos escribir nuestras aplicaciones de React con este DOM virtual más rápido y no tener que pagar ninguna de las consecuencias por ello?
Y así que si estás interesado, sígueme en Twitter en idynyy o echa un vistazo a mi proyecto, million.dev en la web. Muchas gracias por escuchar. Que tengas un gran día. ♪♪
Comments