A resposta que ficou a mesma por uma década
Nos últimos dez anos, sempre que alguém perguntava como deveria construir um frontend, a resposta era surpreendentemente estável: use um framework. A única questão em aberto era qual — React, Vue, Angular, depois Svelte ou Solid. Que você usaria um nunca esteve em discussão. Um framework não era a escolha; era o ponto de partida a partir do qual você escolhia.
Esse reflexo não é acidente. Os frameworks conquistaram sua dominância com argumentos concretos que se sustentaram por mais de uma década. Mas a própria conta que os fez vencer está sendo refeita agora pela geração de código com IA. Quando um modelo monta uma interface inteira em qualquer stack que você quiser em segundos, a vantagem ergonômica que sustentava o argumento todo encolhe — e os custos que um framework sempre carregou junto ganham um contorno mais nítido. Então a pergunta honesta não é se o próximo framework vai destronar o último. É esta: está acabando a era em que um framework pesado era a resposta óbvia?
Por que os frameworks venceram
Você só entende a virada se levar a sério por que os frameworks venceram para começo de conversa. Não foi hype, e não foi moda. Foram três vantagens muito reais.
A primeira foi o reúso de componentes. Antes do React, você construía interfaces manipulando o DOM na unha — um botão aqui, um handler de evento ali, e a verdade sobre o estado da página espalhada por uma dúzia de lugares que você tinha que manter em sincronia. O React transformou isso num modelo: estado entra, UI sai, como uma função. Você constrói um <DatePicker /> uma vez e o usa cem vezes, e ele se comporta igual toda vez. Foi um avanço genuíno na forma de pensar interfaces.
A segunda foi o ecossistema. Escolher um framework nunca significou escolher só uma biblioteca. Significou entrar num universo inteiro: routers, gerenciamento de estado, bibliotecas de formulário, kits de componentes, utilitários de teste, milhares de perguntas respondidas no Stack Overflow. Decidir pelo React era decidir pelo Next.js, por uma história de deploy, por respostas prontas para problemas que você ainda nem tinha. O ecossistema era o verdadeiro fosso, não a biblioteca no centro dele.
A terceira, e para as empresas muitas vezes a mais importante, era o pool de contratação. Escolher React significava poder pescar num mar de desenvolvedores que já o conheciam. Você não precisava requalificar ninguém. Um novo contratado era produtivo em dias, não em meses, porque já tinha visto os mesmos padrões três vezes em outros lugares. Para uma organização isso não é detalhe — é a diferença entre um time que você consegue escalar e um que depende de conhecimento exótico trancado em algumas cabeças.
Essas três vantagens se juntavam num único argumento de venda que se erguia acima de tudo: velocidade de desenvolvimento. Um framework deixava os times mais rápidos. Tirava do seu colo o mesmo encanamento de sempre e te deixava construir o produto em vez da infraestrutura. Essa era a promessa, e ela era em grande parte verdadeira. E é justamente essa promessa que a IA está atacando agora.
O que a IA muda na conta
O ponto crucial é pouco espetacular e ainda assim decisivo: a geração ficou barata, e barata independentemente do stack. Um modelo monta pra você uma visão de tabela com ordenação, paginação e estados de carregamento tão rápido em React quanto em Vue ou em HTML puro com um punhado de handlers de evento. O esforço de colocar uma interface de pé pela primeira vez caiu, para o humano, para praticamente zero em todos os stacks igualmente.
Isso faz algo com o argumento principal do framework. Se "velocidade de desenvolvimento" significava o framework te presentear com a primeira versão rápida — então agora o modelo te presenteia com isso, em todos os stacks. A velocidade que costumava ser a vantagem do framework não é mais um diferencial. Virou o mínimo esperado, disponível em qualquer lugar. A distância ergonômica entre "com framework" e "sem framework" encolhe exatamente no momento em que o humano deixa de ser quem digita a primeira versão.
E uma vez que a velocidade de escrita é nivelada, os custos que o framework sempre carregou — os custos que você aceitava pagar porque a velocidade os compensava — entram em cena. O tamanho do bundle. A pipeline de build com suas cinco ferramentas. As árvores de dependência com seus mil pacotes transitivos. E acima de tudo o churn — o cansaço de quem migrou ao longo dos anos de componentes de classe para hooks para server components, de Webpack para Vite, de um paradigma de busca de dados para o seguinte. Cada uma dessas migrações custou semanas e entregou ao usuário do site: nada. Enquanto o framework te deixava mais rápido, você aceitava essa fatura. Quando a velocidade é a mesma em todo lugar, o outro lado da balança pesa mais.
Há aqui, porém, uma reviravolta que você não pode dar ao luxo de ignorar. Os modelos não são igualmente bons em todos os stacks. Eles são melhores naquilo que mais aparece no material de treinamento — e isso é, por larga margem, React e Next.js. Um modelo escreve um React mais confiável do que Svelte, simplesmente porque viu mil vezes mais React. Isso produz um paradoxo de consolidação: a própria ferramenta de IA que em teoria torna todo stack igualmente barato, na prática torna o stack já dominante ainda mais atraente. Deixe o modelo te ajudar, e você é empurrado — de forma suave, mas incessante — exatamente para onde todo mundo já está. A IA não democratiza a escolha de stack. Ela a centraliza.
A contracorrente: menor, mais perto dos padrões, mais chato
Em paralelo, e não por acaso, ganha terreno um contramovimento que aponta para longe do framework — de volta para a própria plataforma.
Estão os Web Components: componentes como padrão da web, rodando direto no navegador, sem framework por baixo. Custom elements e o shadow DOM entregam o encapsulamento que antes era o motivo de carregar um framework junto — só que agora embutido, sem data de validade. Está o HTMX, que simplesmente inverte a premissa do single-page app: em vez de buscar JSON e renderizar no cliente, o servidor manda HTML pronto, e alguns atributos no markup trocam os fragmentos certos. Para uma faixa inteira de aplicações — formulários, listas, dashboards, CRUD — isso não é menos capaz, é radicalmente menos complicado. Está a postura HTML-first em geral, e a fórmula "vanilla mais um pouquinho": os navegadores modernos hoje fazem de forma nativa muito do que antes você puxava num pacote, e o buraco você preenche com algumas linhas em vez de um ecossistema.
O que une essas abordagens não é nostalgia. É a constatação de que boa parte daquilo pelo qual compramos frameworks ou migrou para a plataforma ou ficou barato por causa da IA. O churn do ecossistema JS — aquela sensação de que o que você aprendeu ano passado já é a coisa errada este ano — carrega um custo que mais times agora lançam abertamente como prejuízo. E um padrão não envelhece do mesmo jeito: HTML de 2015 ainda renderiza em 2026. Uma toolchain de frontend de 2015 é arqueologia.
A pergunta de verdade mudou
Junte esses fios e o que muda é menos a resposta do que a pergunta. Por uma década ela era: "Qual framework?" Você escolhia entre React, Vue e Angular, e a escolha definia todo o resto.
A pergunta que importa hoje é outra: "Qual é a menor coisa que entrega e permanece manutenível?" Isso não é um encolhimento retórico, mas um ponto de partida diferente. Para um portfólio de marketing com três elementos interativos, a resposta honesta talvez seja HTML com uma pitada de JavaScript — e um modelo escreve isso pra você com o mesmo prazer com que escreveria um app React, só que depois não há pipeline de build para manter. Para uma aplicação altamente interativa com estado compartilhado complexo, a resposta honesta talvez ainda seja React — não por hábito, mas porque o problema genuinamente justifica a maquinaria. O ponto é que o framework deixa de ser uma suposição padrão e vira uma decisão que você precisa justificar. Você não o usa mais porque sempre usa um. Você o usa quando a tarefa merece.
Só para continuarmos honestos: os frameworks não estão morrendo
E agora a parte que você não pode pular, porque senão fica a lição errada. Nada do que foi dito acima significa que React e companhia vão desaparecer. Muito pelo contrário — várias das forças que descrevi empurram para o outro lado, e a análise mais honesta tem que dizer isso.
A consolidação dos dados de treinamento que apresentei como paradoxo é o motivo mais forte pelo qual os frameworks estabelecidos estão ficando mais grudentos, não mais soltos. Um modelo produz, por larga margem, o código mais confiável num framework popular e amplamente representado. Ele conhece os idiomas, as armadilhas, os erros típicos e suas correções, porque viu milhões de exemplos. Num stack obscuro ou novíssimo ele alucina APIs com mais frequência, recorre a padrões desatualizados e produz código que parece plausível e quebra de forma sutil. Quem escolhe hoje um stack exótico com o argumento "tanto faz, a IA faz tudo mesmo" está apostando contra a própria ferramenta com a qual pretende trabalhar. Essa aposta dá errado com mais frequência do que a história da IA sem limites sugere.
Somado a isso: as três vantagens originais não sumiram. O pool de contratação do React ainda é enorme. O ecossistema ainda é profundo. E o reúso de componentes ainda resolve um problema real que nenhum gerador, por mais rápido que seja, faz desaparecer por mágica — a saber, consistência ao longo de uma base de código grande e de vida longa. Um modelo pode te gerar um botão dez vezes; se ele gera o mesmo botão dez vezes é outra história. Foi exatamente para isso que o modelo de componentes foi inventado.
O movimento pragmático, portanto, é muitas vezes o oposto da rebeldia. É este: apoiar-se no mainstream bem suportado — porque o modelo é mais confiável ali, porque você encontra gente para mantê-lo, porque daqui a cinco anos alguém ainda entende o que está escrito. "O framework está morrendo" é uma manchete de efeito. "O framework não é mais o padrão reflexo, mas em muitos casos ainda é a escolha certa" é a versão verdadeira e mais incômoda.
Conclusão
A era em que "use um framework" era a resposta completa está chegando ao fim — mas não porque os frameworks estão morrendo. Está chegando ao fim porque a pergunta mudou. Enquanto o humano digitava a primeira versão, a velocidade de desenvolvimento era o argumento decisivo, e o framework a entregava. Agora a geração a entrega em todo stack, e o que sobra são os velhos custos — complexidade, churn, peso de bundle — de um lado, e a nova consolidação do mainstream do outro. Os dois puxam em direções opostas, e é justamente por isso que não existe mais uma resposta genérica, só uma pergunta melhor: qual é a menor coisa que entrega e permanece manutenível?
É exatamente assim que tomamos a decisão na NH Labs. Não escolhemos um stack porque ele recebeu uma ovação de pé numa conferência, e não jogamos o React pela janela porque um blog o declarou morto. Pesamos duas coisas uma contra a outra: quão manutenível isso é ao longo dos anos — e com que confiabilidade os modelos com que construímos dão suporte justamente a esse stack? Às vezes a resposta é HTML com uma pitada de JavaScript e nenhuma pipeline de build. Às vezes é React, porque o problema merece e porque as ferramentas o dominam melhor. O que ela nunca é: uma escolha padrão reflexa ditada pelo último hype. É por isso que nossos clientes podem contar que aquilo que entregamos não só roda hoje, como daqui a cinco anos ainda será entendido e alterado por alguém.