Criei um app em todos os frameworks frontend
Outra ótima leitura da Alicia. Confira os links abaixo para encontrar mais de seu excelente trabalho! 
TL;DR
Qual framework você deve usar? Bem, isso depende do que você está desenvolvendo e quais são suas prioridades. Mas criei uma ferramenta de comparação rápida para ajudá-lo a encontrar o stack perfeito para seu projeto. Veja: Stack Match.
Quer apenas os números? Também construí o mesmo app usando 10 frameworks diferentes e fiz benchmarks. Veja o repositório framework-benchmarks para código-fonte e resultados.
Metodologia
Por que estou escrevendo isso? Bem, vejo muitos artigos promovendo frameworks específicos ou criticando outros. Mas raramente o autor consegue cortar o hype e fornecer uma comparação imparcial entre todas* as opções.
Meu objetivo aqui é descrever brevemente a proposta única de cada framework, quando você deve usá-lo, abordando seus prós, contras e também mencionar meus pensamentos.
Falando sobre imparcialidade, preciso construir o mesmo app em cada framework para tornar este um teste justo (o que fiz!). Mas esse é o primeiro problema, pois apps simples não demonstram totalmente as capacidades de um framework em cenários do mundo real. Como tal, também incluí projetos reais/ativos que construí com cada um. Todos esses estão prontos para produção, com um número decente de usuários ativos e/ou downloads (na verdade, um total de 1 milhão de usuários anuais e 50 mil estrelas no GitHub).
Como existem literalmente centenas de frameworks frontend, para manter este post razoável, vou cobrir apenas os “top” 10 mais recentes e melhores, e estamos focando principalmente na experiência do desenvolvedor (mas benchmarks de performance também serão inclusos).
Chega de conversa, vamos lá!
React
React está em todos os lugares, alimentando mais de 1,3 milhão de sites e usado por muitas (provavelmente a maioria) grandes empresas. Está por aí há mais de 12 anos, apoiado pela Meta, com ferramentas muito maduras e um grande ecossistema. Não é à toa que se tornou a escolha padrão para muitos times. É muito estável com excelente compatibilidade com versões anteriores (o que na verdade também é um de seus problemas, pois há múltiplas formas de fazer tudo).
Mas não é perfeito. Adiciona muito boilerplate tornando muito mais verboso escrever do que em Svelte ou Vue. O DOM virtual também adiciona uma sobrecarga de performance bastante significativa (na verdade, apenas a reconciliação, mas é fácil usar incorretamente), memoização é frequentemente manual, recursos concorrentes ainda não são muito maduros, e bundles tendem a ser grandes, mesmo com muito tree shaking.
Prós
- Muitos empregos
- Onipresente, ecossistema enorme, bom suporte da comunidade, apoio corporativo
- Flexibilidade, construir qualquer coisa desde SPAs, emails até apps mobile (meio que)
Contras
- Embora seja rápido começar, React pode ser lento para dominar adequadamente, e há muitas coisas que podem confundir iniciantes
- Menos performático por padrão, e o DOM virtual adiciona uma sobrecarga
- Bastante pesado em boilerplate, especialmente quando comparado a Svelte ou Solid
Meus Pensamentos
Se você está fazendo code vibe, React tem uma enorme vantagem, já que há tanto código por aí para os AIs consumirem. Da mesma forma, se você está procurando um emprego, não pode errar aprendendo React, pois tem sido o framework dominante para a maioria das empresas há um tempo.
Dito isso, pessoalmente não gosto de React: é lento, pesado, chato e às vezes um pouco mais complexo do que outros frameworks.
Acho frustrante precisar fazer tanto trabalho manual para melhorar a performance de um app. Torna o código verboso e propenso a erros. Mesmo que as ferramentas do desenvolvedor sejam muito boas, inspecionar a saída compilada ainda pode ser bem doloroso. Passo muito mais tempo com os docs abertos, pois a especificação do React é bastante grande e ampla.
O que construí
Vue
Vue é um framework progressivo, o que significa que pode ser usado para todos os tipos de app, desde apenas um script drop-in para aprimorar HTML até uma SPA completa com SSR. Como Svelte, usa SFCs (componentes de arquivo único) onde cada arquivo .vue agrupa template, lógica e CSS com escopo. Para reatividade, Vue usa ES2015 Proxies para rastrear dependências e atualizar apenas o necessário, sem memoização manual.
Prós
- Realmente fácil, intuitivo e rápido de aprender e usar
- Componentes de arquivo único agradáveis com estilos com escopo
- Reatividade fina e fácil com rastreamento eficiente de dependências
- Ferramentas oficiais para roteamento, estado e SSR (agrupadas separadamente)
Contras
- Embora Vue possa escalar muito bem, muito pensamento é necessário ao usá-lo para um projeto muito grande
- Há algumas inconsistências (como as duas APIs concorrentes Options vs Composition)
- Algumas ressalvas de reatividade (por exemplo, .value em refs, desestruturação perde reatividade)
Meus Pensamentos
Vue pode ser visto como o framework Goldilocks, sentando-se confortavelmente entre a flexibilidade do React e a estrutura do Angular. Vue é rápido o suficiente, divertido o suficiente e testado em batalha o suficiente, mas não realmente se destaca incrivelmente em nenhuma dessas áreas.
O sistema de reatividade usando Proxies é genuinamente impressionante. Mude uma propriedade de dados e tudo que depende dela se atualiza automaticamente. E o ecossistema é muito mais forte do que as pessoas percebem.
Escolhi Vue para Dashy, porque tinha tudo que eu precisava, mas também é incrivelmente fácil, então colaboradores poderiam adicionar seus próprios widgets e recursos, sem uma curva de aprendizado acentuada.
O que construí
Svelte
Svelte consistentemente se classificou como um dos frameworks mais amados, e com razão. É simples, rápido, leve e realmente divertido. Reatividade é construída diretamente na linguagem, sem hooks, proxies ou estranheza de useEffect; apenas atribua a uma variável e ela reage.
Ao contrário de muitos outros frameworks, não envia um runtime ou usa um DOM virtual. Em vez disso, componentes são compilados em JavaScript vanilla altamente otimizado no tempo de construção. Então, não há sobrecarga de runtime, nenhum código de framework no seu bundle e você obtém performance próxima à nativa no navegador. Ah, e a saída compilada é surpreendentemente legível.
Prós
- Bundles menores e mais rápidos do que React ou Vue
- Modelo de reatividade realmente simples
- Menos boilerplate do que qualquer outro framework
- Animações são integradas
Contras
- Ecossistema ainda menor do que React/Vue
- SvelteKit ainda em maturação e pode ser ligeiramente menos estável do que Next/Nuxt
- Para grandes times ou projetos enormes, as ferramentas não são tão robustas
Meus Pensamentos
Construir em Svelte me deixa feliz. Gosto que seja moderno, intuitivo e rápido, mas também que seus SFCs estejam muito alinhados com as tecnologias web principais: apenas HTML, CSS e JS.
Svelte tem sido minha escolha para construir coisas rapidamente e lindamente, enquanto entrego um resultado performático. Mas descobri que se não prestar atenção à estrutura, um projeto grande pode ficar bagunçado rapidamente.
Não necessariamente o usaria para um enorme dashboard corporativo onde você tem 15 times trabalhando no mesmo codebase, React ou Angular ainda oferecem mais previsibilidade, estabilidade e ferramentas nesses cenários.
O que construí
Angular
Você provavelmente está pensando que Angular é um framework antigo, usado apenas em apps legados e ambientes corporativos. E sim, o último está correto, mas lançamentos recentes (sim, ainda é muito ativo) têm alguns recursos incríveis que o tornam uma escolha muito viável em 2025.
Ao contrário de outros frameworks, Angular envia tudo com baterias incluídas: roteamento, formulários, HTTP, testes, internacionalização, animações, SSR e muito mais - tudo oficialmente mantido e profundamente integrado. Sem necessidade de juntar um stack.
Mas pode ser verboso para escrever.### Prós
- TypeScript desde o início
- Muito estável nos dias de hoje
- Tudo o que é necessário para aplicativos grandes está incluído
- Compilação AOT de templates, tornando-o mais rápido que alguns
- Muitos empregos no mundo corporativo
Contras
- Curva de aprendizado mais acentuada (RxJS, DI, módulos, zones)
- Verboso em comparação com frameworks como Svelte ou Vue
- Comunidade menor que React/Vue em código aberto ou tutoriais
- Menos flexível — você constrói do jeito Angular
Meus Pensamentos
Angular não é cool, mas é consistente, poderoso e escalável. Não há realmente nada faltando, então você não precisa fazer npm install de um monte de dependências de terceiros apenas para fazer tarefas comuns.
Não achei complicado me atualizar, mas havia muito que eu precisava aprender na documentação, especialmente com a sintaxe de template, definições de componentes, diretivas, injeções, etc. A única coisa com a qual tive dificuldade foi inicialmente fazer a hidratação funcionar para minhas rotas SSR. Tudo o mais foi tranquilo.
Eu consideraria Angular novamente para aplicativos grandes, onde estabilidade, estrutura e suporte de longo prazo importam, mas não tanto para aplicativos menores.
O que construí
Lit
Lit é um framework super leve para construir Web Components baseados em padrões, construído em torno de APIs modernas do navegador (como Custom Elements e Shadow DOM) e é ótimo quando você quer componentes de UI reutilizáveis e agnósticos de framework.
Prós
- Usa Web Components nativos e padrões comuns
- Performático, pois não há virtual DOM, e as atualizações são mínimas e diretas
- Funciona com qualquer framework (ou nenhum)
Contras
- Sintaxe verbosa: @click, ?disabled, .value, etc.
- Componentes baseados em classe parecem desatualizados
- SSR é experimental e difícil de configurar
- Ecossistema e recursos de aprendizado são nicho
Meus Pensamentos
Pessoalmente, achei que escrever componentes Lit era um pouco como voltar aos velhos tempos do React. Os componentes são baseados em classe, e até mesmo os componentes mais simples são bastante verbosos, com uma quantidade considerável de código boilerplate.
A sintaxe de expressão engraçada (para atributos) me pegou algumas vezes, esquecendo de preceder propriedades com um ., booleanos com um ?, event listeners com um @ e todos os valores com um $
A renderização no servidor ainda é experimental, e foi uma dor de cabeça fazer funcionar em um projeto standalone Vite + Lit.
Como é web-components e usa o shadow DOM, cada componente é totalmente isolado. O que tem seus prós e contras, mas se você não está acostumado com isso, você pode notar que coisas como seu reset CSS global ou estilos não funcionam da forma que você esperaria.
O que construí
Marko
Marko é uma linguagem declarativa e um framework web de alto desempenho, construído e mantido pelo eBay.
Prós
- Sintaxe concisa, com opções de abreviação para markup, sem necessidade de importar componentes/tags customizadas
- SSR e componentes de UI isomórficos bem fáceis
- Roteamento fácil com Marko run
Contras
- Muito nicho e suporte limitado - você definitivamente não conseguiria fazer pair programming com Marko!
- Incrível quando funciona, mas se você enfrentar um problema, você estará mergulhando no código-fonte do Marko e resolvendo você mesmo
- Documentação faltando (ex: Low level APIs está apenas vazio)
Meus Pensamentos
Eu realmente gostei do que Marko estava tentando fazer, o templating fazia muito sentido. Mas parece um pouco como usar um framework do futuro, mas no passado, é tanto futurista quanto desatualizado ao mesmo tempo.
O principal inconveniente, e é um grande — era que há informações muito limitadas online. A documentação é escassa, você não pode apenas fazer grep no github para encontrar exemplos, ferramentas de IA não têm ideia dos conceitos básicos do Marko, há suporte comunitário limitado e até mesmo o intellisense é muito limitado. Então, se você enfrentar problemas, você estará mergulhando no código-fonte do Marko você mesmo. E ele tem alguns quirks, que muitas vezes não são documentados (ex: se você usar class {} em uma view ou layout de nível superior, toda a interatividade simplesmente quebrará, sem uma mensagem de erro).
Então, por mais que eu tenha gostado de trabalhar com Marko, não sinto que posso recomendá-lo para nenhum projeto sério, apenas porque a comunidade é tão pequena. Também não acho que será mantido ativamente por muito mais tempo, pois a atividade do repositório tem desacelerado nos últimos anos, e o eBay parece ser o único mantenedor principal.
O que construí
jQuery
Você pensou que eu esqueceria do nosso velho amigo jQuery?! Quase 20 anos desde seu primeiro lançamento, e jQuery ainda está presente em mais de 70% dos 100 mil principais websites (isso está amplamente correlacionado com o uso do WordPress).
Esse número agora está começando a declinar, e com razão - para aplicativos simples, muitos dos recursos do jQuery agora podem ser feitos nativamente com JavaScript moderno, e para aplicativos mais complexos, frameworks modernos simplesmente fazem o trabalho muito melhor.
…mas no início deste ano, e pela primeira vez desde 2016, uma nova versão principal, jQuery 4 foi publicada.
Prós
- Sem ferramentas de build, gerenciadores de dependência, transpiladores, etc
- É muito testado em batalha
- Útil para suportar navegadores (muito) antigos que não têm os recursos mais novos de JavaScript
Contras
- Não há muito que jQuery possa fazer, que não possa ser feito com JavaScript vanilla
Dito isto, não consegui me trazer a construir um aplicativo moderno usando jQuery. Embora eu tenha usado (muitos anos atrás) para revision-quizzes, intern-magnet e user-monkey.
Alpine
Permite que você facilmente adicione reatividade ao HTML renderizado no servidor (sem SPAs, sem hidratação, sem SSR). É ideal para melhorias simples de UI sem uma configuração de build completa.
O que é inteligente é como o Alpine fica fora do seu caminho. O HTML ainda é legível, o JavaScript é mínimo, e tudo se degrada graciosamente se o Alpine não carregar. É progressive enhancement feito corretamente - a página funciona sem JavaScript, mas se torna interativa quando carrega.
A sintaxe lê naturalmente: x-on:click="searchWeather()", x-text="temperature", x-bind:class="{'active': isExpanded}". É declarativo como templates Vue mas vive direto no HTML. As atualizações reativas acontecem automaticamente quando você modifica os dados.
Prós
- Zero configuração — funciona com apenas um ``` tag
- Ideal para pequenos aprimoramentos em SSR ou sites estáticos
- Sintaxe fácil e declarativa inspirada em Vue
- Aprimoramento progressivo por padrão
Contras
- Não é adequado para aplicativos grandes — falta roteamento, gerenciamento de estado, SSR, etc
- Ferramentas e estrutura limitadas para grandes equipes
- Pode ficar bagunçado se você colocar muita lógica em atributos HTML
Meus Pensamentos
Alpine atinge um ponto muito bom para interatividade simples. Quando você não quer um framework completo e apenas precisa de modais, dropdowns, toggles ou comportamento leve no lado do cliente, Alpine é perfeito.
O que construí
Solid
Solid parece muito com React à primeira vista, mas por baixo dos panos é completamente diferente e muito mais rápido. Em vez de um DOM virtual, Solid usa reatividade de granulação fina (semelhante aos internals do Svelte e Vue) para atualizar apenas o que realmente mudou. O resultado são bundles minúsculos, quase nenhuma sobrecarga de runtime e ótimo desempenho.
Você ainda escreve JSX, ainda define componentes, ainda usa hooks - mas tudo é reativo por padrão. Signals (createSignal) substituem useState, computações são executadas automaticamente quando suas dependências mudam, e nada é re-renderizado desnecessariamente. Parece familiar, mas sem as partes desconfortáveis do React.
Prós
- Extremamente rápido: sem DOM virtual, reatividade de granulação fina, bundle minúsculo
- Parece familiar, se você vem de um background React
- Muito escalável, para interfaces altamente interativas e grandes
Contras
- Ecossistema e comunidade muito menores
- SSR é forte, mas frameworks full-stack como SolidStart ainda estão amadurecendo
- JSX.
Meus Pensamentos
Solid parece “o que React poderia ter sido” se fosse projetado hoje. Você obtém a ergonomia do React sem a dança de re-renderização, hacks de memoização ou armadilhas de desempenho. Realmente parece ágil construir com ele. Mas como ainda é relativamente nicho, você não encontrará tantas bibliotecas, tutoriais ou ofertas de emprego.
O que construí
Astro
Astro é menos um framework e mais um construtor de sites focado em conteúdo.
Astro constrói seu site estaticamente e usa quase nenhum JavaScript por padrão. A interatividade vem de “ilhas”, que são componentes isolados e minúsculos, escritos com qualquer framework de sua escolha (como React, Svelte, Vue, Solid, etc), e são usados para adicionar interatividade que é hidratada no lado do cliente, apenas quando necessário.
Prós
- Melhor opção para SEO (SSG, SSR), além de todos os benefícios de interatividade apenas quando você precisa.
- Suporte de primeira classe para MD/MDX
Contras
- É bom para sites com muito conteúdo, mas definitivamente não é uma boa escolha para SPA/aplicativos interativos
Meus Pensamentos
Para um blog, documentação, um site de marketing ou um projeto “principalmente estático com alguns bits interativos”, é honestamente difícil de superar. Eu amo Astro, sua DX e flexibilidade, mas tem um caso de uso muito específico.
O que construí
Van.js
Van é um framework de UI reativo minúsculo (sério, minúsculo - menos de 1kb) Grab 'n Go sem DOM virtual, sem ferramentas de build, sem dependências e sem abstrações pesadas. Funciona inteiramente com nós DOM simples, usando primitivos reativos simples (van.state, van.derive) para atualizar a UI quando os dados mudam. Parece mais próximo de “JavaScript vanilla reativo” do que um framework tradicional.
A API é intencionalmente mínima. Você cria componentes como funções que retornam elementos DOM, vincula estado diretamente em suas chamadas semelhantes a markup, e é… praticamente isso. Sem JSX, sem compilador, sem bundler, sem hooks de ciclo de vida sofisticados. Apenas JavaScript e APIs DOM com um toque de reatividade.
Prós
- Extremamente pequeno e rápido, perfeito para pequenos widgets ou componentes incorporados
- Sem etapa de build; funciona em uma tag
<script> - Modelo de reatividade muito simples
- Fácil de aprender se você estiver confortável com JavaScript vanilla
Contras
- Definitivamente não adequado para aplicativos maiores
- Nenhuma abstração de componente além de funções, nenhum sistema de templating, nenhum sistema de eventos
- Incrível para reatividade simples, mas fica complicado rapidamente para qualquer coisa maior
O que construí
Qwik
Qwik é meio selvagem. Ele repensa completamente como os aplicativos web funcionam fazendo algo chamado “resumability” - sua página carrega instantaneamente com zero JavaScript, então componentes individuais acordam apenas quando você interage com eles. É como ter uma página da web que está dormindo até você mexer nela.
Prós
- TTFB super baixo, com <1KB JS no carregamento inicial
- Escala muito bem para aplicativos grandes com rotas complexas ou conteúdo dinâmico
- Ergonomia familiar do desenvolvedor, com JSX + Vite + signals + roteamento baseado em arquivos
Contras
- SSR é obrigatório, não pode funcionar puramente no lado do cliente
- Curva de aprendizado mais acentuada, e alguns conceitos (como resumability e serialização) podem parecer estranhos para desenvolvedores no início
- Depuração pode ser complexa, porque a lógica é dividida entre limites de servidor
Meus Pensamentos
Se você está trabalhando em um aplicativo muito grande ou complexo, que também precisa ser altamente performático, então Qwik é uma opção natural. Claro que tem uma comunidade menor, curva de aprendizado mais acentuada e é mais complexo do que outras opções, mas quando cada byte importa, esse é apenas o preço a pagar.
O que construí
Espera - Não é um teste justo se você construiu aplicativos diferentes!
Esse é um ponto muito justo, mas não se preocupe - eu tenho você!
Para comparar esses frameworks de forma mais imparcial, também construí um mini-app idêntico em cada um deles e fiz benchmark de cada um para comparar o desempenho.
Você pode verificar isso aqui: GitHub - Lissy93/framework-benchmarks: 🌈 The same app built in 10 different frontend frameworks. For automated performance benchmarking.
Há um conjunto de testes compartilhado para confirmar que cada aplicativo atende aos mesmos requisitos, cada aplicativo usa todos os mesmos ativos e estilos compartilhados, e então tenho um conjunto de scripts de benchmark de desempenho que executam todos os testes de desempenho reais. Esses resultados são então processados e colocados no branch results, junto com alguns gráficos e resumos que estão no readme principal e na homepage do framework-benchmarks.
Conclusão
Pronto, 12 frameworks, 12 aplicativos (e 12 anos de dor). Se você está tentando escolher um framework para seu próximo projeto, confira Stack Match, a ferramenta de comparação de frameworks.
E se você gosta desse tipo de conteúdo, considere me seguir 
Sou @Lissy93 no GitHub, e @lissy93 aqui no DEV. Construo muitas ferramentas para desenvolvedores, aplicativos de segurança e privacidade e coisas auto-hospedáveis para Linux, que você pode conferir no meu site https://010000010110110001101001011000110110100101100001.com (sim, um nome de domínio realmente memorável!)
De qualquer forma, obrigado por ler, feliz codificação e feliz ano novo!!
Ah, e quase esqueci - qual framework é verdadeiramente o melhor? Bem, esse teria que ser obviamente [limite de caracteres atingido]