Hay muchos motores de juegos en el mundo: Unreal Engine, Unity Engine, Godot Engine, Cry Engine y más.

¿Qué tienen en común estos motores de juego? Personalización. Los diferentes juegos tienen diferentes requisitos y necesitan características específicas para lograr sus objetivos. Es difícil proporcionar todas las funciones posibles en un solo programa, razón por la cual muchos motores permiten a los desarrolladores modificar el código fuente y crear sus propias funciones personalizadas. La personalización es una parte esencial de estos motores.

Ahora, volvamos al desarrollo frontend. React es uno de los frameworks más populares en este espacio. Pero, así como modificar el motor es común en el desarrollo de juegos, ¿es tan común modificar el código fuente interno de React en el desarrollo frontend? Esta simple pregunta revela mucho sobre lo que realmente buscamos y resalta la diferencia de dirección entre el desarrollo frontend moderno y otros campos.

React es un marco que es casi imposible de modificar. Se le recomienda utilizar React tal cual, y no está destinado a que los desarrolladores personalicen su arquitectura interna ni su proceso de renderizado. Por lo tanto, usar React significa que debes resolver todos tus requisitos dentro de los límites de la estructura de React. Pero el mundo está lleno de requisitos diversos y no todos pueden resolverse dentro del marco de React.

"No existe el almuerzo gratis."
"No existe ninguna herramienta que pueda hacerlo todo."

React es solo una herramienta de desarrollo y tiene sus límites.

La razón principal por la que los desarrolladores usan React es la productividad. React se creó con la pregunta: "¿Cómo podemos desarrollar componentes DOM de manera más eficiente en el desarrollo web?" En el centro del enfoque de React está el DOM. Así como las funciones automatizadas generalmente significan una falta de personalización, la "productividad" de la que hablan a menudo significa "no se puede modificar el bucle de renderizado estrechamente acoplado con el navegador a través del DOM virtual".

El primer problema importante con React es el DOM. No todo gira en torno al DOM y no todos los programas funcionan únicamente en torno a él. Sin embargo, React coloca el DOM en el centro de su filosofía. La sintaxis JSX, donde cada componente devuelve algo "similar a un elemento HTML", refleja claramente esta mentalidad.

El segundo problema es el DOM virtual. Así es como funciona el DOM virtual:

• El DOM es inherentemente lento.
• Para mitigar esto, React introduce una lógica interna más rápida.
• Esta lógica crea un objeto que copia la forma del árbol DOM real, conocido como DOM virtual. Cada vez que se produce el renderizado, React encuentra los cambios usando este DOM virtual y solo actualiza esas partes.
• Para implementar este sistema, las actualizaciones de DOM siempre deben pasar por el elemento DOM raíz.
• Lo virtual DOM funciona a la perfección con las operaciones internas de React.

La pregunta es, ¿por qué HPSE adoptaría un sistema de este tipo en primer lugar? Además de la preocupación de que este enfoque de renderizado no pueda abordar varios requisitos de HPSE, la mayor preocupación es su falta de utilidad real en este contexto.

En HPSE, los componentes DOM se pueden administrar a nivel de clase. Cuando se crea una instancia, su referencia DOM div de nivel superior se almacena como una variable miembro. Los métodos privados de la instancia pueden manipular directamente la referencia DOM o usar querySelector() para acceder a ella. En la mayoría de los casos, esto sería más rápido que comparar todo el árbol DOM.

Usar el DOM virtual es solo una forma de identificar cambios, pero si ya tiene los cambios almacenados internamente dentro de su instancia, buscarlos nuevamente es redundante. Una vez que se actualiza el elemento DOM, el navegador seguirá activando ReFlow y RePaint, por lo que no hay diferencia en el rendimiento posterior.

El problema final radica en las "operaciones internas" de React. ¿Cuáles son exactamente estas operaciones internas? Falta documentación o información detallada y la mayoría de los desarrolladores frontend tampoco la comprenden completamente. El cliente del navegador ya opera dentro de la capa de abstracción del propio navegador, lo que lo hace vulnerable a varios desafíos. Los procesos internos opacos e inmodificables de React solo exacerban esta vulnerabilidad.

Los cambios en los componentes de React deben pasar por el DOM virtual, y el DOM virtual es administrado por la arquitectura Fiber, que sigue reglas de prioridad específicas. Sin embargo, hay poca documentación sobre cómo personalizar las funciones internas de React para satisfacer las demandas de rendimiento en tiempo real o sincronización de precisión de HPSE. Es como desarrollar un juego AAA con un motor que no se puede personalizar.

"¿Por qué molestarse?"

Es una pregunta que sigue surgiendo.

React está tan estrechamente acoplado internamente que incluso si quisieras modificarlo, no podrías. Nunca fue diseñado con ese propósito en mente. Además, la fuerte combinación de renderizado y actualizaciones de estado hace que React no sea adecuado para proyectos HPSE, donde los componentes no visuales como datos o elementos 3D deben administrarse junto con elementos DOM.

En HPSE, el tiempo de las llamadas a eventos y el desmontaje de la memoria puede no estar vinculado a componentes individuales, pero React aplica esta estructura basada en componentes, lo que dificulta el manejo de dichos requisitos. El diseño de React, donde los cambios de estado en los componentes pueden afectar todo el árbol de renderizado, también entra en conflicto con la necesidad de HPSE de minimizar o controlar dichos impactos.

Bibliotecas como React Three Fiber (R3F) te permiten crear instancias como Mesh o Scene usando una sintaxis "HTML Element Like", pero eso es simplemente Three.js adaptado a la estructura de React. El alto nivel de acoplamiento dentro de React solo empeora el problema de las partes internas no modificables.

El enfoque de manejo de eventos de React también es problemático. React utiliza un sistema de eventos sintéticos para garantizar la compatibilidad del navegador y la coherencia en el manejo de eventos. Sin embargo, al agregar una capa de abstracción al procesamiento de eventos, este sistema limita el control detallado sobre los bucles de eventos y la sincronización necesarios en HPSE, lo que dificulta la implementación de optimizaciones esenciales.

Estos problemas surgen porque la filosofía de diseño de React es fundamentalmente diferente de los objetivos de HPSE. React no se creó pensando en HPSE; fue diseñado para optimizar el desarrollo de clientes web estándar. Si React hubiera seguido una dirección similar a HPSE, sus características habrían sido muy diferentes y habría motivos para adoptarlo en el desarrollo de HPSE. Pero como sus objetivos son tan divergentes, inevitablemente se separan.

Esto no quiere decir que todo lo relacionado con React, como el enrutamiento o useEffect, sea malo. De hecho, la mayoría de estas funciones se pueden implementar utilizando módulos o código JavaScript independientes. A diferencia de React, los módulos generales de JavaScript no imponen canalizaciones o reglas específicas en los proyectos. Además, si son de código abierto, puedes modificar sus componentes internos para adaptarlos a tus necesidades.