Un equipo de desarrollo pasó del «abrumador VDOM» de React a las modernas API de DOM. Inmediatamente vieron mejoras en la velocidad y la interacción.
Para desarrollar la interfaz de usuario de su navegador web, Edge, Microsoft comenzó recientemente a alejarse de React y otros frameworks de JavaScript para adoptar lo que llamó un enfoque de «HTML first». En lugar de usar React para crear la interfaz de usuario -el paradigma de desarrollo web más común hoy en día-, el equipo de Microsoft Edge pivotó hacia un enfoque que describió como «markup-first, pequeños paquetes y menos código JavaScript de renderizado de UI.»
Julien Moulis es un desarrollador frontend senior en una empresa de TI suiza llamada Eukleia, que está construyendo una herramienta para desarrolladores personalizada llamada Mindsapp. Para Mindsapp, su equipo «decidió hacer el cambio de la abrumadora VDOM de React a la fantástica API DOM moderna.»
«Hace unos meses, decidimos hacer la transición de una parte de nuestra aplicación de React a vanilla JavaScript».
– Julien Moulis
Vamos a entrar en lo que eso significa en breve, pero primero quiero citar a Moulis sobre lo que cambió y el impacto que tuvo en sus usuarios finales.
«No podía entender cómo, para sólo actualizar texto, analizar un VDOM y todas las concurrencias y cientos de funciones, podía ser más rápido que sólo actualizar el elemento DOM en sí. Así que construí un pequeño SSR Node.js, para datos reactivos y enrutamiento, RxJS para los componentes web frontend – y redujimos el tiempo de carga en algunas páginas con muchos datos, de 6 segundos a 300ms.»
En resumen, Moulis racionalizó su aplicación pasando de un complejo framework virtual basado en DOM (React) a un enfoque más simple y directo utilizando tecnologías web modernas, lo que resultó en tiempos de carga mucho más rápidos para los usuarios.
¿Cómo lo hizo?
«Hace unos meses, decidimos cambiar una parte de nuestra aplicación de React a JavaScript». Describió la aplicación de su empresa, Mindsapp, como «una aplicación de código bajo para permitirnos desarrollar aplicaciones más rápido: es una aplicación hecha por desarrolladores para desarrolladores.»
Dado que el objetivo de Mindsapp es ayudar a los desarrolladores a acelerar su desarrollo, al equipo le preocupaba que React estuviera ralentizándolo.
Contenido de la página
Los problemas de React en Mindsapp
«La cuestión es que sentíamos que nuestras necesidades ya no se alineaban con el paradigma de React».
Una de las características de Mindsapp es un creador de páginas, donde las páginas son una red de grafos construida con Neo4j. Moulis explicó cómo había funcionado la versión de React que utilizaba páginas:
«Cuando solicito un formulario, recibo un objeto que contiene, entre otras cosas, un array de elementos. [Hasta ahora, cuando recibía estos elementos, los pasaba por una función recursiva que construía los distintos componentes de React a partir de un mapa indexado por la propiedad ‘component’. Una vez renderizados, el usuario tenía acceso a todas las interacciones básicas del formulario, la navegación, etc.».
También utilizaron la API de contexto de React y reductores «para gestionar todos los datos y actualizaciones», y para el enrutamiento utilizaron React-router.
Había un par de problemas clave con este enfoque de React. El primero eran los «renders innecesarios» – a pesar de que habían hecho «esfuerzos significativos para optimizar usando los hooks disponibles». El segundo eran los problemas con el enrutamiento. «Como las páginas eran objetos devueltos por el backend», dijo Moulis, “no podíamos definir todas las rutas de antemano”.
Después de pensar en los problemas, Moulis se hizo esta pregunta: «¿Cómo puede ser más rápido modificar un simple valor de entrada y mostrar un simple span con el texto introducido a través de un framework que accediendo directamente a ese elemento?».
Esto le motivó a buscar una solución más cercana a la plataforma del navegador.
«El caso es que sentimos que nuestras necesidades ya no se alineaban con el paradigma React», me dijo, y añadió: »Recalco que este es un caso específico para nosotros.»
Implementación del enfoque de la API DOM nativa
Después de varios intentos de modificar la estructura de su app, Moulis y su equipo finalmente «optaron por acercarse a las APIs DOM nativas.»
«Nos sorprendió completamente la ganancia de velocidad».
«Para ello, configuramos un sencillo servidor SSR (Node) para prerenderizar nuestros objetos backend y producir nuestros componentes a través de un sencillo analizador de cadenas de plantillas y un mapa», explica.
He aquí el resumen de lo que hizo el equipo de Mindsapp, según Moulis:
«Para lograrlo, nuestro componente Link envía solicitudes directamente al servidor SSR. Si la respuesta es buena, el SSR devuelve la página; si hay un error, envía una página 500 o 404, que podemos configurar en nuestro creador de páginas. También configuramos un simple RxJS fromEvent directamente en el objeto ventana para manejar la navegación nativa del navegador, que a su vez también envía peticiones al servidor SSR».
Esto les llevó un mes de implementación, pero los resultados se notaron inmediatamente después.
«Nos sorprendió mucho el aumento de velocidad», afirma Moulis. «Nuestro motor de aplicaciones está diseñado para producir aplicaciones complejas de tipo ERP, que implican un gran consumo de datos para presentar en tiempo real. En una página que consideramos compleja, con más de 800 elementos DOM, algunos de los cuales utilizan diferentes sistemas de suscripción a través de nuestro sistema de eventos en la inicialización para actualizarse cuando es necesario, el tiempo de carga global bajó de 4-5 segundos a 400ms.»
«En términos de interacción, se acabaron las comprobaciones interminables para asegurarse de que un hijo no se actualiza aunque se actualice el estado del padre».
Además de ganar en velocidad, las interacciones con el usuario mejoraron notablemente, afirma Moulis.
«En términos de interacción, se acabaron las comprobaciones interminables para asegurarse de que un hijo no se actualiza aunque se actualice el estado del padre. Un ejemplo sencillo y trivial: un usuario puede querer cambiar el color de fondo de una tarjeta al hacer clic, que a su vez contiene un gráfico. Podemos hacerlo sin preocuparnos de si el gráfico se actualiza o no».
Inconvenientes
Moulis reconoce, sin embargo, que el enfoque HTML-first tiene sus inconvenientes. Describe los Web Components como «muy farragosos» y señala que «nos convertimos en responsables de garantizar que todas las suscripciones hechas por los elementos se limpien adecuadamente cuando los elementos se destruyen».
Añadió que encontrar desarrolladores que conozcan JavaScript de vanilla y no sólo los frameworks conocidos fue una «dificultad inesperada.»
«No obstante», dijo, “la ganancia para el usuario es enorme, y esa ha sido siempre nuestra prioridad”.
