Eu acompanho há um bom tempo o mercado de Web e participei de várias fases e mudanças de paradigmas, que demoram décadas para ser implementadas e que, muitas vezes, o usuário comum nem faz ideia do esforço empenhado para acontecer.

Primeira revolução: XMLHttpRequest

A primeira grande revolução da web, no meu ponto de vista, ocorreu por volta dos anos 2000 e, apelidada carinhosamente de Ajax, foi criada pela equipe do Outlook Web Access da Microsoft (segundo a Wikipédia). Até então todas as requisições HTTP obrigatoriamente passavam por digitar uma URL na barra de endereços do navegador, clicar em Hyperlink ou algumas outras técnicas obscuras de JavaScript. O XMLHTTPRequest foi a forma criada para realizar requisições HTTP e HTTPS em background, interagindo diretamente com os contents via JavaScript e DOM. O que considero como sendo o primeiro grande projeto usando Ajax foi o Gmail. Sim, esse mesmo, que todo mundo usa (se você usa outro, considere rever seus conceitos, por favor). Barras de progresso, atualizações na tela sem reload, carregamento e envio de informações em realtime... Mas esse padrão, hora aclamado, se mostrou ineficiente para algumas coisas, já que os protocolos HTTP 1 e 1.1 foram desenhados para fluxos direcionais, em que uma requisição enviada aguarda uma resposta. Servidores web frequentemente passam por problemas de sobrecarga, quando o processamento backend demanda muito tempo a ponto de agarrar a fila de retorno, criam-se os famosos erros 400, 408, 500, 502, 504, 508, entre outros, de acordo com a implementação. Em resumo, dependendo da carga, seu servidor web pode não conseguir responder à requisição, tornando o serviço inacessível.

Segunda revolução: ECMA 2015, 2016 e 2017

Nos anos de 2015, 2016 e 2017 saíram oficialmente os padrões mais importante para web no meu ponto de vista. Para quem não conhece, o ECMAScript é uma linguagem inspirada no JavaScript, com padrões definidos pelo European Computer Manufacturers Association, instituição fundada em 1961 e dedicada à padronização de sistemas da informação. Essa organização internacional tem como membros Apple, Google, Meta, Microsoft, PayPal, IBM, entre outros. Os padrões ES2015 (ou ECMA 5, 6 e 6+) foram implementados no JavaScript, introduzindo orientação a objeto (parcialmente), Promises, Arrow Functions, Canvas, Websocket, WebGL, WebAssembly, Service Workers, som e vídeo nativos dos navegadores (que seria de fundamental importância para morte do Flash) e a criação de vários serviços incríveis que temos hoje. Sem esses padrões, a forma como escrevemos para web atualmente não existiria e, muito provavelmente, o Node.js não seria tão bom quanto é.

Perceba uma coisa curiosa: qual a necessidade de um socket bidirecional, controle de renderização por GPU, funções não bloqueantes, interfaces binárias de outras linguagens e serviços independentes background multi-thread em um navegador? Para jogos realtime sem precisar baixar, talvez? Fazer sistemas operacionais inteiros acessíveis via web? Ou, ainda, para criar hardwares de interfaces em nuvem mais simples, talvez? Quem sabe, fornecer qualquer tipo de serviço de stream como vídeos, jogos e músicas que temos hoje? Particularmente, eu acho que todas as alternativas citadas e algumas que ainda vamos ver nos próximos anos. Por isso os investimentos bilionários em 5g, voltando à era dos mainframes superpotentes em datacenters cloud de grandes empresas e serviços de assinatura para tudo.

Terceira revolução: HTTP/2

Ok, mesmo com tudo que foi implementado nos padrões ECMA, a forma de se desenvolver na web não mudou muita coisa. Ainda utilizamos padrões REST em APIs HTTP/1.1 e poucas empresas de fato desenvolveram ferramentas avançadas com Websocket. Então por que não tornar o HTTP um socket bidirecional, mantendo o suporte nativo paraa tudo que funciona hoje e permitido a troca de streams? Parece uma boa ideia, não é mesmo? Eu gosto bastante da ideia, mas acredito que os recursos mais avançados continuarão sem ser utilizados, pois o padrão Rest está quase que marcado a fogo no peito de desenvolvedores web. Durante todos esses anos participei de vários projetos que utilizaram Websocket cuja performance é infinitamente melhor. É possível implementar todas as camadas de autenticação e segurança do HTTP graças à remoção quase que total do Header de requisição, suporte a pacotes binários, e pelo fato do socket permanecer ativo durante a navegação. Não existe DNS Lookup, TTFB, SSL Checker em cada requisição ou retorno, fora que o servidor pode enviar comunicações diretas, sem a necessidade uma requisição do client.

Porém, no meu ponto de vista, o maior problema do Ajax, Websocket e HTTP/2 é que tornar a página humanamente mais amigável para navegação, como sistemas SPA, é péssimo para indexadores de busca. É uma briga eterna entre agradar os usuários e o Google, criando medusas como o SSR (Server Side Rendeing).

Quarta revolução: Reatividade (puramente especulação)

Esse tópico é puramente especulativo, mas com os anos eu tenho acertado com certa frequência minhas previsões, tanto que trabalho com Node.js desde 2012, em suas primeiras versões, me tornando um dos primeiro desenvolvedores do Brasil em uma época que o .NET e PHP dominavam. Hoje praticamente todas as linguagens de backend possuem elementos ou referências diretas ao Node.js e NPM.

Ok, mas como seria isso, então? Se a evolução lógica idealizada pelas grandes empresas são as aplicações bidirecionais em stream, o controle de estado da aplicação precisa esta diretamente no servidor e reagir às alterações, seja por meio de eventos client-side ou mudanças server-side, como alterações no banco de dados, filas de processamento, etc., respeitando devidamente a seguranças e níveis de acessos dos dados pelos usuários, porém sem a necessidade de APIs de requisições. Pense, por exemplo, num sistema de corretoras Web3, que faz cotação em tempo real dos criptoativos para compra e venda de ativos, essas informações realtime são acessados por milhares de pessoas no mundo todo, por meio de Websocket e sistemas de telemetria, uma espécie de broadcast para todos que estão escutando o serviço. No mercado de varejo passamos por algo similar, o Google definiu como padrão do Google Shopping sistemas de APIs de telemetria para atualização de dados do produto, sendo assim todos os varejos que desejam se plugar ao Google Shopping terão necessidade de dispor desse tipo de serviço, substituído os antigos XMLs.

Se você é desenvolvedor web, imagine realizar pesquisas no banco de dados pelo frontend, sem precisar de APIs e seu sistema atualizar tabelas de dados em tempo real, sem que seja necessário codificar, apenas escutando um serviço e processando os dados em seu Angular, React ou Vue. Imagine enviar tarefas para filas, disparar milhares de e-mails com feedback em tempo real, sem uma API intermediando. Isso é a reatividade da web3, a camada entre servidor e cliente 100% abstraída.

Reatividade para Web