O mundo do desenvolvimento web passou a maior parte de uma década tentando se convencer de que o navegador deveria realizar o trabalho pesado. Começamos com documentos e formulários, e então migramos constantemente todas as operações concebíveis para o cliente. Roteamento, gerenciamento de estado, busca de dados (data fetching), lógica de renderização e até a orquestração de consultas ao banco de dados via GraphQL — tudo isso foi para dentro de bundles de JavaScript que cresciam cada vez mais a cada lançamento. Os frameworks se multiplicaram, os pipelines de build se tornaram mais complexos e o que começou como uma forma de tornar os apps mais ágeis transformou-se em uma arquitetura onde uma página não conseguia renderizar um único pixel significativo até que megabytes de código fossem baixados, analisados e executados.
Essa mudança resolveu problemas reais. Páginas renderizadas no servidor com um toque de jQuery tinham dificuldade em entregar as transições suaves e semelhantes a aplicativos que os usuários esperavam. As Single Page Applications nos deram navegação instantânea, estado persistente e interações ricas. Mas o custo se acumulou. As equipes agora gerenciam stores de estado complexos no lado do cliente, lidam com bundles de JavaScript massivos, mantêm camadas de sincronização de dados delicadas e depuram pipelines de build que, às vezes, parecem um trabalho de tempo integral por si só. Trocamos um conjunto de problemas por outro, e muitos desenvolvedores agora questionam se cada aplicação precisa pagar esse imposto.
Dois desenvolvimentos estão tornando essa pergunta mais fácil de responder.
HTMX e o Retorno do Hypermedia
O primeiro é o HTMX. Superficialmente, parece uma biblioteca pequena, mas sua implicação arquitetural é enorme. O HTMX trata o HTML como o formato nativo para a lógica da aplicação, em vez de tratá-lo como uma casca estática que deve ser inflada por JavaScript.
Aqui está o que muda na prática. Tradicionalmente, quando um usuário clica em um botão para carregar mais comentários, o frontend dispara uma requisição fetch, recebe um payload JSON, o normaliza em um store no lado do cliente, o processa através de um template de componente, faz o diff do virtual DOM e, finalmente, aplica o patch na página. O HTMX encurta essa cadeia. O próprio botão contém atributos que dizem ao navegador para onde enviar a requisição e qual elemento da página deve ser substituído. O servidor retorna um fragmento de HTML — apenas os novos comentários, envolvidos em uma div. O navegador o substitui na tela. Não há JSON, não há árvore de estado no frontend, não há algoritmo de reconciliação e não há JavaScript imperativo para manter a UI sincronizada com o servidor.
Isso não é uma rejeição ao desenvolvimento moderno. É uma rejeição à abstração desnecessária. O HTMX prova que o hypermedia, o estilo arquitetural que impulsionou a web primitiva, ainda pode suportar interfaces sofisticadas quando combinado com uma ergonomia moderna. Qualquer elemento pode emitir requisições, não apenas formulários e links. Qualquer evento pode disparar uma atualização. O servidor permanece como a fonte da verdade tanto para os dados quanto para a apresentação.
Atualizações Parciais Declarativas do Chrome
A segunda mudança é mais recente e vive dentro do próprio navegador. O Chrome está introduzindo as Atualizações Parciais Declarativas, ou DPU (Declarative Partial Updates). Este recurso permite que um navegador faça o streaming de HTML e o insira diretamente em partes específicas de uma página conforme os bytes chegam.
Antes do DPU, se você quisesse fazer o streaming de dados em tempo real para uma página web, geralmente recorria a WebSockets, Server-Sent Events ou long-polling combinados com manipulação manual do DOM. O frontend tinha que gerenciar a conexão, analisar o payload e decidir exatamente como e onde injetar a marcação. O DPU muda a equação ao tornar o processo declarativo. O desenvolvedor especifica um container de destino, e o navegador cuida do resto: recebe o stream, analisa o fragmento e o coloca exatamente onde ele deve estar, mesmo antes de a resposta completa ser encerrada.
Pense em um dashboard de monitoramento mostrando logs de servidor ou uma fila de suporte sendo atualizada em tempo real. Com o DPU, o backend envia pedaços (chunks) de HTML puro conforme são gerados. O navegador faz o streaming deles para o corpo de uma tabela ou para um container de feed sem uma única linha de lógica de streaming no lado do cliente. A montagem acontece nativamente.
O Modelo Server-First
Una o HTMX e o DPU e você terá uma arquitetura coerente onde o servidor detém o estado e gera a UI, enquanto o navegador cuida da exibição e da entrada do usuário. Frameworks de backend como Rails, Laravel, Django, templates de Go ou ASP.NET tornam-se novamente a camada de interface primária. O frontend não é uma aplicação separada que consome uma API. Ele é a interface de hypermedia que o servidor produz.
This model fits a surprisingly wide slice of software. Consider the typical SaaS application. It is dashboards with sortable tables. It is admin panels with forms and filters. It is internal tools that move records from one state to another. It is CRUD workflows that show a list, expose a detail view, and let the user edit fields. It is even AI interfaces where a language model streams tokens back to the user, and each token or paragraph can be wrapped in HTML and appended to the conversation thread. For all of these, a thick JavaScript client is often overkill.
The benefits are immediate and practical. Initial page loads are faster because the first meaningful paint arrives as HTML, not after a hydration cycle completes. JavaScript payloads shrink because there is no virtual DOM, no client-side router, and no state management library to ship. Search engines see complete content without executing bundles, so SEO works by default. Complexity drops because one codebase handles routing, business logic, and rendering. Debugging gets easier. When something looks wrong, you inspect the Network tab and see exactly what HTML the server sent. There is no opaque client-side state object to reverse-engineer.
What About React and Heavy Clients?
None of this means React is dead, or that SPAs are a mistake. Complex, editor-grade applications still need a thick client. Figma runs a C++ engine compiled to WebAssembly inside the browser because server round-trips would make drawing impossible. Canva manipulates the canvas at sixty frames per second with client-side geometry. Google Docs uses operational transforms to resolve editing conflicts in milliseconds. These tools are essentially desktop applications delivered through a browser tab. They are not going back to server-rendered forms.
But most software is not Figma. Most software is not a real-time graphics editor. Most software is a reporting screen, a configuration panel, a booking flow, or a content management form. For that long tail of applications, shipping hundreds of kilobytes of JavaScript framework just to toggle a modal or fetch a list of records never made much sense. The economics of the stack are shifting. We are rediscovering that the server can be close to the user thanks to the edge, and that the browser itself has grown capable enough to update fragments without a framework intermediating every byte.
The Pendulum Finds a Balance
The arc of web architecture is swinging back toward simplicity, but it is not a naive return to the nineties. The browser is becoming smarter. Features like DPU do not replace developer ingenuity; they absorb the patterns we used to implement by hand — streaming, partial updates, targeted DOM insertion — into the platform itself. HTMX gives us the vocabulary to express those behaviors without reconstructing a miniature operating system in the frontend.
You no longer have to choose between a simple architecture and a responsive user experience. You can have both. The server can drive the interface, the browser can assemble it, and the JavaScript you write can focus on genuine interactivity rather than plumbing.
For the next generation of dashboards, admin tools, and AI-powered interfaces, the smartest client might be the one that does less.