A web moderna é um milagre da engenharia, mas sua história está repleta de conceitos brilhantes que explodiram em execução. Para cada inovação que deu certo, há uma tecnologia promissora que caiu por terra. Cada uma dessas falhas oferece uma lição prática para nós, desenvolvedores de software.
A nova tecnologia é uma espécie de compulsão. Adoramos contemplar as novas estruturas brilhantes no horizonte, mas a verdadeira sabedoria arquitetônica vem do exame dos destroços. E desde migrações catastróficas de versões e aquisições hostis de HTML por empresas até ignorar as realidades da física da web e as limitações físicas do front-end, temos muitos destroços com os quais aprender.
Aqui estão sete das mais flagrantes falhas de execução na história moderna da web — e as lições arquitetônicas que devemos absorver para garantir que nossas boas ideias não sofram o mesmo destino.
Web SQL: um beco sem saída para um único fornecedor
A boa ideia: Traga um banco de dados relacional robusto diretamente para o navegador local. Habilite aplicativos da web responsivos e off-line. Sincronize tudo com um armazenamento de dados de back-end.
A falha fatal: Política de padrões externos. A Apple impulsionou o Web SQL, mas era essencialmente apenas um wrapper bruto em torno do SQLite. O Google incorporou o Web SQL no Chrome, mas a Mozilla e a Microsoft recusaram porque padronizá-lo significava vincular toda a especificação da web a uma biblioteca C específica. Foi obsoleto.
A lição: Padrões exigem consenso. Vincular a infraestrutura da Web a uma única implementação é uma receita para a descontinuação repentina. Embora os desenvolvedores tenham perdido o Web SQL e sofrido com o desajeitado IndexedDB, o campo finalmente progrediu para campos mais férteis com o PGLite baseado em Wasm e soluções locais mais recentes, como PowerSync.
Angular 2: Queime os navios
A boa ideia: Aproveite o sucesso do Angular com uma versão melhor e completamente reescrita.
Quando Hernán Cortéz queimou os seus navios, revelou-se uma estratégia brilhante. Para uma estrutura web convencional? Nem tanto.
Angular.js era o rei indiscutível dos aplicativos de página única (SPA), mas apresentava gargalos de desempenho. Parecia um kludge de alto funcionamento. O Google queria introduzir uma arquitetura baseada em componentes que a tornasse sustentável, amigável para empresas e de alto desempenho. Mas para fazer isso, eles tiveram que primeiro derrubá-lo até as vigas.
A falha fatal: Estratégia de implementação ruim. O Google anunciou uma reescrita completa e não compatível com versões anteriores que quebrou tudo fundamentalmente. Não havia um caminho de migração claro para bases de código empresariais massivas.
Isso deixou a porta aberta para uma nova estrutura. React entrou por aquela porta e nunca mais saiu.
A lição: Nunca interrompa o caminho de migração. Mesmo um caminho difícil respeita seus usuários atuais, dizendo-lhes que os desenvolvedores valorizam sua participação contínua.
Fluxo do Facebook: tomate de estufa
A boa ideia: JavaScript precisava de segurança de tipo para satisfazer a empresa. O Flow introduziu uma inferência de tipo granular que poderia, teoricamente, proteger bases de código enormes com anotações manuais mínimas.
Infelizmente, o projeto era um tomate de estufa. Foi concebido e nutrido no ambiente corporativo controlado do Facebook.
A falha fatal: O Flow foi construído para o ambiente interno do Facebook. Fora do Meta, o Flow era notoriamente problemático, exigia um servidor de segundo plano pesado, travava no Windows e ignorava o ecossistema de código aberto mais amplo. A Microsoft abordou habilmente a brecha com o TypeScript.
A lição: Um ecossistema aberto e uma experiência de desenvolvedor perfeita sempre superarão vantagens como o pioneirismo e a superioridade técnica bruta. Mesmo se você for uma megacorporação, mantenha o projeto vinculado ao uso ativo e amplo.
Google AMP: a flexibilidade corporativa
A boa ideia: À medida que os dispositivos móveis se tornaram massivos, a web lutou para trazer uma experiência decente para o dispositivo portátil. Os modos arraigados que cultivamos nos últimos 15 anos foram insuficientes, levando a sites móveis lentos e desajeitados, carregados de pacotes pesados e ativos não otimizados.
O Google AMP (Accelerated Mobile Pages) pretendia ser uma abordagem padrão que reduzia o HTML, o JavaScript e as imagens servidas em dispositivos móveis e aplicava um cache CDN (rede de distribuição de conteúdo) universal. O Google teve influência para realizar tudo isso.
A falha fatal: O Google confiou na coerção para fazer o AMP ter sucesso. Além disso, a tecnologia em si era demasiado rígida. O Google tentou forçar os editores a usar um subconjunto proprietário e simplificado de HTML, ameaçando suas classificações de busca. Foi um pesadelo anticompetitivo e anti-inovação.
A lição: Os padrões abertos da web vencem. O aprisionamento do fornecedor disfarçado de “otimização de desempenho” acabará sendo contornado e rejeitado pela comunidade.
Você pode não estar trabalhando em uma potência global, mas coisas semelhantes acontecem mesmo em pequenas e médias lojas. Quando a organização tenta impor padrões rígidos aos codificadores de nível básico, ela pode produzir atrito, ressentimento e rebelião. Editais de cima para baixo raramente funcionam bem no software.
Tempo de execução CSS-in-JS: a ilusão de desempenho
A boa ideia: CSS em escala é notoriamente difícil. Colisões globais de namespaces e guerras de especificidade têm atormentado enormes bases de código há décadas. Colocar estilos diretamente dentro de componentes JavaScript pareceu uma revelação. Ele encapsulou a lógica, eliminou códigos mortos e tornou os estilos de gerenciamento em equipes corporativas distribuídas incrivelmente intuitivos.
A falha fatal: Ignoramos a plataforma subjacente. Em troca dessa bela experiência de desenvolvedor, aceitamos uma implementação de tempo de execução fundamentalmente falha. Passamos cinco anos forçando os navegadores a baixar enormes pacotes de JavaScript apenas para calcular e injetar estilos dinamicamente durante o ciclo de renderização. Pegamos algo que o navegador faz nativamente na velocidade da luz – analisar folhas de estilo – e forçamos o mecanismo JavaScript de thread único a fazer isso, prejudicando o tempo de carregamento inicial e prejudicando o desempenho da CPU móvel.
A lição: Nunca troque o desempenho do usuário pela experiência do desenvolvedor. Quando as abstrações arquitetônicas combatem os recursos nativos do navegador, o usuário final sempre paga o imposto. Eventualmente tivemos que engolir nosso orgulho e lembrar que os navegadores são máquinas de estado altamente otimizadas para analisar CSS nativo. Essa dura lição levou a indústria de volta aos módulos CSS, aos recursos CSS nativos modernos e aos compiladores com tempo de execução zero, como o Tailwind.
Micro front-ends: arquitetura certa, lugar errado
A boa ideia: Aplique dissociação estilo microsserviço ao front-end, permitindo que grandes organizações aumentem a agilidade ao distribuir o desenvolvimento de diferentes recursos de UI entre diferentes equipes.
Quebrar a UI monolítica em componentes menores e separados que poderiam ser desenvolvidos, testados e implantados de forma independente prometia os mesmos benefícios que os microsserviços proporcionavam no lado do servidor: equipes autônomas, bases de código menores, manutenção mais fácil, atualizações incrementais. Todos poderíamos trabalhar com mais liberdade e nos mover mais rápido. Mas e o pobre usuário final?
A falha fatal: Pegamos um padrão de back-end distribuído e o aplicamos à força no navegador. Realmente não fazia sentido. Os microfront-ends resolveram um problema organizacional, mas criaram complexidade, sobrecarga enorme e problemas de desempenho no dispositivo do usuário final. Em vez de um aplicativo coeso, as equipes acabaram enviando vários pacotes JavaScript, dependências duplicadas e, ocasionalmente, versões totalmente concorrentes de estruturas de UI na mesma página. O navegador foi forçado a atuar como árbitro de sistemas distribuídos, levando a estados fragmentados, degradação de desempenho e metacomplexidade.
A lição: A Lei de Conway não deve ditar o pacote do lado do cliente. Só porque uma arquitetura distribuída resolve gargalos de escalabilidade de back-end não significa que ela pertence ao cliente. Você nunca deve degradar a experiência do usuário final para resolver um problema no organograma corporativo. Se você estiver flertando com uma solução que introduz complexidade, siga o bom senso.
Em vez de micro front-ends, o que realmente precisávamos eram módulos ECMAScript e uma infraestrutura moderna sem construção.
SPAs somente do lado do cliente: a computação distribuída ataca novamente
A boa ideia: Use o navegador como uma plataforma para oferecer uma experiência nativa e de cliente espesso. Gerencie o estado localmente, de forma reativa.
A falha fatal: Sempre que você replica o estado, você apresenta os problemas da computação distribuída. Isso é inevitável na web. O cliente exige que o estado seja útil para o usuário. Em aplicativos de página única, conforme comumente entendidos, temos um mecanismo JavaScript executando o estado do usuário e sincronizando-o com o back-end por meio de JSON.
Uma camada arquitetônica inteira é dedicada à tradução de mensagens JSON entre os clientes e o armazenamento de dados. Grande parte da lógica de negócios está concentrada no cliente. O cliente é inteligente, o servidor é burro.
A lição: O servidor existe por um motivo. A indústria passou os últimos cinco anos construindo meta-frameworks massivos apenas para voltar à renderização do lado do servidor usando Next.js e frameworks full-stack semelhantes.
Contos de advertência
Não é a coisa que você vê chegando que te pega. É aquilo em que você não pensou. Muitas vezes é a arrogância ou o entusiasmo excessivo que nos leva a lugares sombrios. O conhecimento técnico avançado e a ávida capacidade de fazer podem estar atrelados a circunstâncias imperfeitas. Somente a vigilância impedirá que os projetos de software sigam em frente. É preciso verificar continuamente como as implementações estão realmente indo, e não como o plano diz que deveriam.
Se os pesos pesados da tecnologia nesta lista puderem ser ultrapassados por resultados tão infelizes, devemos reconhecer que isso pode acontecer connosco. Esse reconhecimento é em si a melhor apólice de seguro.
