¿Qué es exactamente una "aplicación web de alto rendimiento" o "frontend"?

Desde el declive de la era de Internet Explorer, el ecosistema JavaScript se ha vuelto cada vez más poderoso y el término "frontend" se ha convertido en sinónimo de clientes web modernos y de alto rendimiento. En el centro de este mundo "frontal" se encuentra React. De hecho, no usar React en el desarrollo frontend a menudo hace que uno parezca un caso atípico.

Pero así como no todos los juegos son AAA, debemos considerar cuidadosamente lo que queremos decir con "alto rendimiento" cuando hablamos de aplicaciones web. Esta distinción es crucial para el tema que nos ocupa hoy.

1. El alcance de las aplicaciones web de alto rendimiento

En la mayoría de los casos, el término "aplicación web de alto rendimiento" se refiere a un cliente web dinámico e interactivo creado utilizando marcos basados ​​en JavaScript como React, Vue o Angular. Estas aplicaciones generalmente cuentan con tiempos de carga rápidos y enrutamiento del lado del cliente, y el DOM virtual de React juega un papel importante en la mejora de la velocidad de renderizado.

Sin embargo, existen aplicaciones web que utilizan los 4 GB del límite de memoria del módulo WASM, están diseñadas teniendo en cuenta la administración sistemática de la memoria y apuntan a un rendimiento a la par con programas nativos como Blender o 3Ds Max. Estas aplicaciones se alinean más con el concepto de "programas" que aprovechan todos los recursos de una pestaña del navegador, en lugar de las tradicionales "páginas web" optimizadas para SEO.

Aunque los entornos de navegador actuales aún pueden tener dificultades para ofrecer un rendimiento similar al nativo debido a los límites de memoria y la sobrecarga, los objetivos de dichas aplicaciones son fundamentalmente diferentes. Manejan grandes conjuntos de datos y apuntan a utilizar los 2 a 4 GB completos de memoria, al mismo tiempo que buscan las velocidades de renderizado más altas.

Dado que los problemas que enfrentan este tipo de aplicaciones web difieren de los que enfrentan las aplicaciones típicas de "alto rendimiento", las direcciones que siguen también divergen.

La "aplicación web de alto rendimiento" mencionada al principio y la que describo aquí son fundamentalmente diferentes en sus caminos. Agruparlos bajo un solo término sería problemático. Necesitamos una terminología diferente para reflejar estas diferencias.

Por eso propongo que dejemos de referirnos a esta última como "aplicación web de alto rendimiento" o "frontend" y en su lugar utilicemos los siguientes términos:

• Ingeniería de marco de alto rendimiento basada en navegador (BBHPFE)
• Ingeniería de sistemas de alto rendimiento (HPSE) (basada en navegador)

Creo que estos términos definen claramente la diferencia de requisitos entre frontend y HPSE. No todos los clientes basados ​​en navegador son una interfaz; algunos son HPSE. Considere el siguiente ejemplo para comprender por qué es importante esta distinción:

[Conversación 1]

R: "Estoy desarrollando una aplicación frontend pero no uso React".
B: "¿Una aplicación frontend sin React? ¡React tiene más del 60% de participación de mercado en frontend! ¿Por qué no la usarías?"

[Conversación 2]

R: "Estoy desarrollando una aplicación HPSE pero no uso React".
B: "Eso tiene sentido para HPSE. Las empresas de juegos a menudo personalizan ampliamente sus motores, pero las funciones internas y el proceso de renderizado de React no se pueden modificar. Nunca fue diseñado para ese propósito".

Ahora, analicemos los componentes esenciales que debe tener un HPSE.

2-1. Gestión de la memoria
No se puede hablar de programas de alto rendimiento sin abordar la memoria. Ya sea que se utilice un recolector de basura o se libere manualmente la memoria asignada dinámicamente, la memoria no utilizada siempre debe liberarse.

Considere un juego basado en navegador en el que el jugador se mueve a un nuevo mapa. El juego deberá obtener nuevos datos de mapas del servidor de forma asincrónica, crear nuevas mallas y eliminar las antiguas. También se deben liberar los datos utilizados para generar la malla antigua.

Si las referencias a los datos antiguos no se publican correctamente, el uso de la memoria seguirá creciendo con cada transición del mapa. Una vez que alcance alrededor de 2 GB, es posible que encuentre un error de "Memoria insuficiente" y el navegador se bloqueará.

Es cierto que JavaScript no fue diseñado para el control de memoria de bajo nivel; ni ​​el lenguaje ni la filosofía de sus desarrolladores lo priorizan. No estoy diciendo que la gestión de la memoria sea siempre crucial, pero como dicen, "no existe el almuerzo gratis". Si es necesaria la gestión de la memoria, debe hacerse.

2-2. Flexibilidad en el cumplimiento de requisitos
Una vez escuché a alguien decir: "Cuando pases de ser un desarrollador junior a un desarrollador intermedio, deberías poder crear cualquier cosa que se te solicite".

JavaScript ya es un lenguaje impresionante con pocas limitaciones inherentes (aparte de los límites de memoria). Si quieres construir algo, probablemente puedas hacerlo.

La verdadera pregunta es si su proyecto actual realmente puede adaptarse a una amplia variedad de requisitos.

Así como las máquinas en una fábrica se averían después de un funcionamiento continuo, la búsqueda de funciones personalizadas y de alto rendimiento conduce inevitablemente a enfrentar desafíos inesperados. Cuando esto sucede, la flexibilidad y la capacidad de cumplir requisitos únicos son esenciales.

Por ejemplo, ¿alguna vez has oído que Lost Ark se creó con Unreal Engine 3? Unreal Engine 5 ya está disponible, pero todavía usan Unreal Engine 3, que fue creado en 2004. Para sostener el proyecto hasta ahora, deben haber realizado modificaciones extensas en el motor, prácticamente una revisión completa. Debido a las características del juego, tuvieron que personalizar constantemente el proceso de renderizado y el bucle con técnicas como renderizado diferido, creación de instancias, selección y reflexión del espacio de la pantalla para cumplir con los requisitos estéticos y de rendimiento.

La capacidad de modificar el código fuente del motor era fundamental. Si el motor se hubiera cerrado o acoplado demasiado estrechamente para permitir modificaciones, es posible que Lost Ark nunca se hubiera desarrollado.

HPSE es lo mismo. Si bien el entorno ha cambiado a uno basado en navegador, la necesidad de funciones personalizadas y modificaciones flexibles sigue siendo la misma. Por lo tanto, las bibliotecas y los módulos externos utilizados en HPSE deben ser modificables, y si el proceso de renderizado del navegador o el acoplamiento del módulo interno es demasiado rígido para permitir estos cambios, se convierte en un problema importante.

2-3. El inevitable enfoque orientado a objetos
Cuando se trata de programas a gran escala, una cosa se vuelve inevitable: la programación orientada a objetos (POO).

JavaScript es un lenguaje multiparadigma y la programación funcional (FP) se utiliza ampliamente. Sin embargo, FP, aunque es adecuado para clientes web, rara vez se usa en programas a gran escala donde múltiples objetos interactúan de manera compleja porque las instancias en FP carecen de estados internos.

React compensa esto con la gestión del estado global y useEffect, pero no es tan intuitivo como hacer que cada instancia mantenga su propio estado y controle las llamadas a métodos a través de métodos públicos.

Si bien la programación orientada a objetos no siempre es la mejor opción, es difícil pensar en una alternativa mejor cuando se consideran las necesidades de desarrollo altamente personalizadas de HPSE. Muchos programas a gran escala, incluidos sistemas operativos y juegos, se crean utilizando principios de programación orientada a objetos. Incluso las fuentes de motores más populares están orientadas a objetos, con pequeñas variaciones en la metodología.

Los desarrolladores que han participado en proyectos a gran escala probablemente estén familiarizados con la programación orientada a objetos. Esto hace que el desarrollo basado en programación orientada a objetos sea propicio para la colaboración.

Dicho esto, no es necesario descartar los puntos fuertes de JavaScript. Dado que JavaScript admite funciones y declaraciones constantes, las funciones de módulo simples que no requieren instancias se pueden definir como objetos literales usando const o funciones. Esto puede mejorar la productividad y aprovechar la versatilidad de JavaScript.

En conclusión, creo que un enfoque multiparadigma, que incorpore principios orientados a objetos, sería ideal para HPSE.