O que exatamente é um "aplicativo web de alto desempenho" ou "frontend"?

Desde o declínio da era do Internet Explorer, o ecossistema JavaScript tornou-se cada vez mais poderoso, e o termo "frontend" tornou-se sinônimo de clientes web modernos e de alto desempenho. No centro deste mundo “frontend” está o React. Na verdade, não usar o React no desenvolvimento front-end muitas vezes faz com que alguém pareça um estranho.

Mas assim como nem todo jogo é AAA, devemos considerar cuidadosamente o que queremos dizer com “alto desempenho” quando discutimos aplicativos da web. Esta distinção é crucial para o tema em questão hoje.

1. O escopo dos aplicativos da Web de alto desempenho

Na maioria dos casos, o termo "aplicativo web de alto desempenho" refere-se a um cliente web interativo e dinâmico construído usando estruturas baseadas em JavaScript como React, Vue ou Angular. Esses aplicativos normalmente apresentam tempos de carregamento rápidos e roteamento do lado do cliente, e o DOM virtual do React desempenha um papel importante no aumento da velocidade de renderização.

No entanto, existem aplicativos da web que utilizam todos os 4 GB do limite de memória do módulo WASM, são construídos com o gerenciamento sistemático de memória em mente e buscam desempenho equivalente a programas nativos como Blender ou 3Ds Max. Esses aplicativos se alinham mais com o conceito de “programas” que aproveitam todos os recursos de uma guia do navegador, em vez das tradicionais “páginas da web” otimizadas para SEO.

Embora os ambientes de navegadores atuais ainda possam ter dificuldade para oferecer desempenho semelhante ao nativo devido aos limites de memória e sobrecarga, os objetivos de tais aplicativos são fundamentalmente diferentes. Eles lidam com grandes conjuntos de dados e pretendem usar 2 a 4 GB de memória, ao mesmo tempo em que buscam as mais altas velocidades de renderização.

Dado que os problemas enfrentados por esses tipos de aplicativos da web diferem daqueles enfrentados por aplicativos típicos de "alto desempenho", as direções que eles seguem também divergem.

O "aplicativo web de alto desempenho" mencionado no início e aquele que descrevo aqui têm caminhos fundamentalmente diferentes. Agrupá-los num único termo seria problemático. Precisamos de uma terminologia diferente para refletir essas diferenças.

É por isso que proponho que paremos de nos referir a este último como um "aplicativo web de alto desempenho" ou "frontend" e, em vez disso, usemos os seguintes termos:

• Engenharia de estrutura de alto desempenho baseada em navegador (BBHPFE)
• (Baseado em navegador) Engenharia de sistemas de alto desempenho (HPSE)

Acredito que esses termos definem claramente a diferença de requisitos entre frontend e HPSE. Nem todo cliente baseado em navegador é um frontend; alguns são HPSEs. Considere o exemplo a seguir para entender por que essa distinção é importante:

[Conversa 1]

R: "Estou desenvolvendo um aplicativo frontend, mas não usando React."
B: "Um aplicativo frontend sem React? React tem mais de 60% de participação de mercado em frontend! Por que você não o usaria?"

[Conversa 2]

R: "Estou desenvolvendo um aplicativo HPSE, mas não usando React."
B: "Isso faz sentido para HPSE. As empresas de jogos geralmente personalizam seus motores extensivamente, mas as funções internas e o pipeline de renderização do React não podem ser modificados. Ele nunca foi projetado para esse propósito."

Agora, vamos discutir os componentes essenciais que um HPSE deve ter.

2-1. Gerenciamento de memória
Você não pode falar sobre programas de alto desempenho sem abordar a memória. Seja usando um coletor de lixo ou liberando manualmente a memória alocada dinamicamente, a memória não utilizada sempre deve ser liberada.

Considere um jogo baseado em navegador onde o jogador se move para um novo mapa. O jogo precisará buscar novos dados de mapa do servidor de forma assíncrona, criar novas malhas e remover as antigas. Os dados utilizados para gerar a malha antiga também devem ser liberados.

Se as referências aos dados antigos não forem liberadas corretamente, o uso de memória continuará crescendo a cada transição do mapa. Quando atingir cerca de 2 GB, você poderá encontrar um erro "Sem memória" e o navegador irá travar.

É verdade que o JavaScript não foi projetado para controle de memória de baixo nível – nem a linguagem nem a filosofia de seus desenvolvedores o priorizam. Não estou dizendo que o gerenciamento da memória é sempre crucial, mas como se costuma dizer, “não existe almoço grátis”. Se o gerenciamento de memória for necessário, isso deverá ser feito.

2-2. Flexibilidade no cumprimento dos requisitos
Certa vez, ouvi alguém dizer: "Quando você passar de desenvolvedor júnior a intermediário, deverá ser capaz de construir qualquer coisa que lhe for solicitada."

JavaScript já é uma linguagem impressionante com poucas limitações inerentes (além dos limites de memória). Se você quiser construir algo, provavelmente isso pode ser feito.

A verdadeira questão é se o seu projeto atual pode realmente acomodar uma ampla variedade de requisitos.

Assim como as máquinas em uma fábrica quebram após operação contínua, buscar recursos personalizados e de alto desempenho inevitavelmente leva ao encontro de desafios inesperados. Quando isso acontece, a flexibilidade e a capacidade de atender a requisitos exclusivos são essenciais.

Por exemplo, você já ouviu falar que Lost Ark foi construído no Unreal Engine 3? O Unreal Engine 5 já foi lançado, mas eles ainda usam o Unreal Engine 3, que foi criado em 2004. Para sustentar o projeto até agora, eles devem ter feito extensas modificações no motor – praticamente uma revisão completa. Devido às características do jogo, eles tiveram que personalizar constantemente o pipeline e o loop de renderização com técnicas como renderização diferida, instanciação, seleção e reflexão do espaço da tela para atender aos requisitos estéticos e de desempenho.

A capacidade de modificar o código-fonte do mecanismo foi crítica. Se o motor tivesse sido fechado ou acoplado demais para permitir modificações, Lost Ark poderia nunca ter sido desenvolvido.

HPSE é o mesmo. Embora o ambiente tenha mudado para um ambiente baseado em navegador, a necessidade de funções personalizadas e modificações flexíveis permanece a mesma. Portanto, as bibliotecas e módulos externos usados ​​no HPSE devem ser modificáveis, e se o pipeline de renderização do navegador ou o acoplamento do módulo interno for muito rígido para permitir essas alterações, isso se tornará um problema significativo.

2-3. A inevitável abordagem orientada a objetos Ao lidar com programas de grande escala, uma coisa se torna inevitável: programação orientada a objetos (OOP).

JavaScript é uma linguagem multiparadigma e a programação funcional (FP) é amplamente utilizada. No entanto, FP, embora adequado para clientes web, raramente é usado em programas de grande escala onde vários objetos interagem de maneiras complexas porque as instâncias em FP não possuem estados internos.

O React compensa isso com gerenciamento de estado global e useEffect, mas não é tão intuitivo quanto fazer com que cada instância mantenha seu próprio estado e controle chamadas de método por meio de métodos públicos.

Embora OOP nem sempre seja a melhor escolha, é difícil pensar em uma alternativa melhor quando se consideram as necessidades de desenvolvimento altamente personalizadas do HPSE. Muitos programas de grande escala, incluindo sistemas operacionais e jogos, são construídos usando princípios OOP. Mesmo as fontes de mecanismo mais populares são orientadas a objetos, com pequenas variações na metodologia.

Os desenvolvedores que participaram de projetos de grande escala provavelmente estão familiarizados com OOP. Isso torna o desenvolvimento baseado em OOP propício à colaboração.

Dito isso, não há necessidade de descartar os pontos fortes do JavaScript. Como o JavaScript oferece suporte a funções e declarações const, funções de módulo simples que não requerem instâncias podem ser definidas como objetos literais usando const ou funções. Isso pode aumentar a produtividade e aproveitar a versatilidade do JavaScript.

Concluindo, acredito que uma abordagem multiparadigma, incorporando princípios orientados a objetos, seria ideal para HPSE.