Porque parei de recomendar React às cegas (e o que uso em vez disso em 2026)

Vue e Svelte não são coisas que se pensam abstratamente às três da manhã, mas foi mais ou menos isso que aconteceu comigo há uns meses, a tentar decidir qual stack recomendar a um cliente que queria "algo moderno, mas que não fosse uma dor de cabeça de manter daqui a dois anos". E percebi que já não tinha uma resposta pronta. Tinha tido, durante anos. Agora já não.

Vou tentar pôr isto por escrito de forma organizada, mas aviso já: não vai sair um artigo comparativo tipo tabela com ticks verdes e cruzes vermelhas. Essas tabelas mentem por omissão constantemente. O que interessa aqui é o que acontece quando o projeto já tem 14 meses, o júnior que herdou o código não percebe metade das decisões arquiteturais, e o deadline de sexta-feira não perdoa ninguém.

Começo pelo React porque é o que todos têm a certeza que já perceberam, e é precisamente aí que mora o problema. O React de 2026 não é o React que a malta aprendeu em 2019 com classes e componentDidMount. É um animal completamente diferente, com Server Components, com a Next.js App Router a empurrar tudo para o servidor de forma quase agressiva, com hooks que ainda dão dores de cabeça a quem não domina bem closures em JavaScript. Uso React profissionalmente desde a versão 16.8, quando os hooks saíram e toda a gente jurou que a vida ia ficar mais simples. Ficou, nalguns aspetos. Noutros, criou uma nova categoria de bugs subtis que nenhum linter apanha sozinho — o clássico "esqueci-me de pôr isto no array de dependências do useEffect e agora o componente re-renderiza 40 vezes por segundo sem eu perceber porquê".

O que ninguém te diz sobre o React em 2026 é que a fragmentação interna do próprio ecossistema já não é sobre bibliotecas de terceiros, é sobre o próprio React. Tens equipas a escrever Server Components como se fossem a solução definitiva para tudo, e tens outras equipas — normalmente as que já foram mordidas por hydration mismatches em produção às duas da manhã — que evitam RSC como quem evita gasolina perto de faíscas. Não é histeria. É trauma genuíno. Lembro-me perfeitamente de um deploy em outubro de 2024, ainda não passava disto para RSC completo, em que um componente que buscava dados de um Postgres via Prisma decidiu, por alguma razão que nunca cheguei a documentar bem, re-executar a query em cada navegação client-side, empurrando o tempo de resposta médio de qualquer coisa como 180ms para uns 2.3 segundos. Ninguém deu por isso durante três dias porque o ambiente de staging tinha cache agressivo a mascarar o problema. Foi um utilizador zangado no Twitter — já nem sei se ainda se chamava assim nessa altura — que nos avisou.

Isto para dizer: a complexidade do React não desapareceu, ela apenas mudou de sítio. Antes vivia no cliente, no gerir de estado, no Redux versus Context versus Zustand versus seja lá o que for que está na moda esta semana. Agora vive na fronteira entre servidor e cliente, num sítio onde a maior parte dos programadores — e digo isto com humildade, porque me incluo aqui às vezes — ainda não desenvolveu instinto suficiente para prever o que vai correr mal antes de correr mal.

E depois há o argumento do ecossistema, que continua a ser, honestamente, o trunfo mais forte do React. Precisas de uma biblioteca para gerir formulários complexos com validação assíncrona e campos condicionais aninhados três níveis? Existe. Precisas de integração com um SDK de pagamentos meio obscuro de um banco regional em Espanha? Alguém já fez isso e publicou no npm, provavelmente mal documentado, mas existe. Esta profundidade de ecossistema não se compra do dia para a noite, e é por isso que continuo a recomendar React para projetos empresariais grandes, com muitas integrações, onde a probabilidade de precisares de "algo esquisito" que já alguém resolveu é elevada. Para uma startup pequena a validar um MVP? Aí já tenho mais dúvidas, e vou chegar lá.

Vue é uma história diferente, e sinto que é sistematicamente subestimado por gente que nunca trabalhou realmente com ele além de um tutorial de fim de semana. A Vue 3 com Composition API resolveu praticamente tudo o que me incomodava na Vue 2 — a Options API tinha um charme genuíno para projetos pequenos, mas escalava mal, ficava difícil de reutilizar lógica sem misturar mixins de forma confusa. A Composition API trouxe algo parecido com hooks do React, mas sem a pegada mental tão pesada em torno de closures e da ordem de execução. ref e reactive são conceitos que consigo explicar a um estagiário em vinte minutos e ele fica a perceber de verdade, não só a decorar padrões.

O que a Vue tem, e que quase ninguém fala com a devoção que merecia, é o Single File Component. Ter template, script e style no mesmo ficheiro .vue parece, à primeira vista, uma decisão estética menor. Não é. Muda completamente o fluxo de trabalho em equipas onde há gente com perfis diferentes — um designer que mexe mais em CSS, um dev mais focado em lógica — porque o contexto está todo ali, sem saltar entre três ficheiros diferentes em três pastas diferentes só para entender um componente de botão. Trabalhei num projeto de e-commerce, lá para 2023, onde migrámos de React para Vue precisamente por causa disto, e a velocidade de onboarding de novos devs melhorou de forma que consigo quantificar mal, mas que se sentiu — três semanas em vez de umas seis ou sete até alguém conseguir ser produtivo sem estar constantemente a perguntar "onde é que isto está definido".

Mas — e aqui vem a parte que a Vue não gosta que se diga em voz alta — o mercado de trabalho continua brutalmente inclinado para React. Não é uma questão técnica. É uma questão de inércia institucional. As grandes empresas já investiram, já têm código legado, já têm equipas formadas, e trocar de stack tem um custo de oportunidade que ninguém quer pagar só porque a alternativa é "mais elegante". Isto significa que se és freelancer, ou se estás a decidir o que aprender para maximizar oportunidades de emprego, Vue continua a ser a escolha do coração e React a escolha da carteira. Detesto dizer isto porque gosto genuinamente mais de escrever Vue no dia a dia, mas fingir que o mercado não existe seria desonesto.

Depois há o Svelte, e aqui confesso que a minha relação mudou bastante nos últimos dois anos. Cheguei a ser cético — achava que era um brinquedo bonito para demos no Twitter, sem substância suficiente para produção séria. Enganei-me redondamente. O Svelte 5, com as runes, resolveu o principal problema que eu tinha com a versão anterior: a reatividade implícita baseada em atribuição de variáveis funcionava bem em componentes pequenos, mas tornava-se opaca e difícil de depurar em aplicações maiores, onde precisas de saber exatamente quando e porquê algo re-renderiza. As runes — $state, $derived, $effect — trouxeram explicitação sem perder a elegância de sintaxe que sempre foi a bandeira do Svelte.

E a proposta de valor central mantém-se genuinamente diferente de tudo o resto: o Svelte não é uma biblioteca que corre no browser, é um compilador. Não há virtual DOM. O código que escreves em .svelte é transformado, em build time, em JavaScript vanilla otimizado que manipula o DOM diretamente. Isto tem consequências reais, não só teóricas. Um projeto meu, um dashboard interno para gestão de conteúdo do chat-to.dev — sim, uso as minhas próprias plataformas como banco de testes, é meio hipócrita mas funciona — tinha um bundle final de cerca de 43kb gzipped em Svelte, contra uma estimativa que fiz depois, reescrevendo o mesmo componente em React com as mesmas dependências, que rondava os 128kb. Não é uma diferença cosmética quando estás a servir utilizadores em zonas com ligação móvel fraca, o que, já agora, é uma fatia maior da audiência do Comuniq.xyz do que eu gostava de admitir publicamente.

Aqui entra uma pequena divagação que talvez não devesse estar aqui mas vou deixar: passei imenso tempo, uns bons três anos, obcecado com performance de frontend de uma forma quase doentia, a medir Lighthouse scores religiosamente, a torturar-me com cada décima de segundo no First Contentful Paint. Percebi eventualmente que isso é um sintoma de outra coisa — provavelmente de não ter confiança suficiente no produto em si, então compensava obsessivamente com métricas técnicas que eram fáceis de otimizar e difíceis de argumentar contra. Ainda hoje luto com esse instinto. Digo isto porque quando falo da leveza do Svelte corro o risco de cair na mesma armadilha — performance importa, mas não é tudo, e conheço projetos Svelte que ficaram tecnicamente lindos e comercialmente mortos porque ninguém validou se alguém queria aquilo.

Voltando. A desvantagem real do Svelte, e aqui sou brutalmente honesto, é o ecossistema. Continua fino. Não fininho ao ponto de ser inutilizável — o SvelteKit amadureceu bastante, a comunidade cresceu de forma consistente desde a versão 5 — mas se precisares de algo muito específico, muito de nicho, a probabilidade de encontrares uma biblioteca pronta cai bastante em comparação com React. Isto obriga, mais vezes do que gostaria, a escrever wrappers próprios à volta de bibliotecas JavaScript vanilla, o que não é o fim do mundo mas consome tempo que um cliente com prazo apertado não costuma querer pagar.

Há ainda a questão do talento disponível, que se liga ao ponto que fiz sobre a Vue mas de forma ainda mais aguda. Contratar um developer Svelte sénior é, honestamente, uma caça ao tesouro. Não é impossível, mas o pool é pequeno, e muita gente que diz saber Svelte na verdade só fez um tutorial ou dois. Isto não é uma crítica ao framework, é só a realidade de adoção — e reflete uma coisa que costumo repetir a quem me pergunta "qual framework devo aprender": a qualidade técnica de uma ferramenta e a probabilidade dela te dar emprego são frequentemente coisas distintas, quase independentes uma da outra.

Deixa-me tentar amarrar isto de uma forma que sirva realmente para decidir, porque até aqui tenho estado principalmente a desabafar sobre cicatrizes de produção, o que é catártico mas pouco prático.

Se estás a construir algo empresarial, com múltiplas integrações esquisitas, uma equipa grande e rotativa, onde a facilidade de contratar substitutos importa mais do que a elegância do código — React continua a ser a escolha defensável, mesmo sabendo que vais herdar a complexidade de RSC e hydration que descrevi lá atrás. Não é a escolha mais bonita. É a mais segura em termos organizacionais, e às vezes é isso que uma decisão técnica precisa de ser.

Se tens uma equipa pequena, product-driven, onde a velocidade de desenvolvimento e a clareza de código importam mais do que o tamanho do pool de talento disponível no mercado — Vue continua, para mim, a melhor relação entre poder e simplicidade cognitiva. É o framework que recomendo com menos hesitação para quase todos os projetos de tamanho médio.

E se performance bruta, tamanho de bundle e experiência de developer minimalista são as prioridades reais — não as prioridades que se dizem em reuniões, mas as que realmente movem a agulha no produto — o Svelte 5 já não é uma aposta arriscada. Já é uma escolha madura, desde que aceites que vais ter de compensar um ecossistema mais magro com mais engenharia própria.

Não vou fingir que existe uma resposta definitiva, porque não existe, e qualquer artigo que te venda isso como certeza absoluta está a mentir-te ou a tentar vender-te um curso. O que existe são trade-offs específicos ao teu contexto, à tua equipa, ao teu prazo, ao teu orçamento de contratação. A pergunta nunca devia ter sido "qual é o melhor framework em 2026", porque essa pergunta não tem resposta séria. A pergunta certa é sempre mais chata e mais específica do que qualquer artigo de blog consegue captar de forma genérica — e se calhar é por isso que ainda ando a escrever sobre isto três anos depois, à procura de uma resposta que sei, no fundo, que não vai aparecer de forma limpa.

Visite sempre: https://chat-to.dev