Tenho visto desenvolvedores que trabalham com C há muito tempo, ainda desenvolvendo com MFC (Microsoft Foundation Classes). A razão é simples: não existem alternativas reais para construir UIs em C . Embora o Qt exista, ele requer uma licença comercial para uso profissional, tornando o MFC a única opção.

MFC fornece componentes básicos de UI, mas ainda é capaz de criar programas de nível de produção, como software CAD ou aplicativos para hospitais.

O estado atual do ecossistema JavaScript é bastante semelhante.

Não existe uma estrutura que tenha sido construída especificamente para atender aos objetivos do HPSE. Embora existam mecanismos de jogos como o Babylon.js, eles oferecem apenas recursos para gráficos 3D e não fornecem uma estrutura abrangente como o React.

Então, no final das contas, tudo se resume ao Vanilla JavaScript e TypeScript. Não é que os desenvolvedores usem Vanilla JavaScript porque adoram; eles usam porque não há outra escolha. Assim como no início, quando os desenvolvedores tinham que construir tudo do zero em C devido à falta de frameworks comerciais, agora enfrentamos a mesma situação em JavaScript. Não existe uma estrutura que atenda totalmente às demandas do HPSE, então nos resta desenvolver manualmente com Vanilla JavaScript.

E, francamente, isso não é exclusivo do JavaScript. Isso também vale para a maioria dos outros idiomas.

Há um ditado que diz: "Não existe almoço grátis."

Muitos dos programas que começaram com grandes ambições de quebrar novas fronteiras acabaram dependendo fortemente de recursos personalizados criados diretamente na linguagem de programação. O HPSE também começou com a visão de um dia rodar programas nativos no navegador e, por enquanto, deve ser escrito peça por peça em Vanilla JavaScript.

Alguns podem argumentar: "Por que não abandonar o JavaScript e usar C ou Rust para criar um módulo WebAssembly (WASM) e executá-lo no navegador?"

Há uma boa história que responde a essa pergunta.

Certa vez, os líderes do Babylon.js e Three.js foram questionados em um comentário se a tecnologia WASM seria o futuro de seus motores. A resposta deles foi "Não."

O motivo é simples: o código C/Rust não é executado diretamente no ambiente web, o que torna a depuração mais difícil. E graças aos avanços do motor V8, o JavaScript agora pode atingir alto desempenho. JavaScript é uma linguagem de script que roda diretamente no navegador e oferece alta produtividade – não há necessidade de abandonar esses pontos fortes.

No passado, os programadores competiam desenvolvendo seus próprios sistemas operacionais. Mas depois que Windows, Mac e Linux se tornaram os padrões, o foco mudou para como construir programas que rodem nesses sistemas. Da mesma forma, os navegadores de hoje evoluíram a um ponto em que é razoável pensar em como construir programas que sejam executados neles.

Se houvesse linhas claras sobre para que JavaScript deveria ou não ser usado, e se tarefas de ponta fossem realmente inadequadas para JavaScript, então a Microsoft nunca teria iniciado o projeto Babylon.js, e Three.js nunca foram criados. O mesmo vale para WebGPU, que está sendo estabelecido como um novo padrão web.

Recentemente, tenho refletido sobre minha identidade como desenvolvedor, questionando o que exatamente significa "frontend" e se esse termo pode realmente abranger o escopo do desenvolvimento de clientes web.

Tenho certeza de que há muita desinformação em meus pensamentos, mas postarei isso como minha primeira entrada no blog para consolidar o que tenho pensado.