A guerra dos frameworks JavaScript acabou

E existe apenas um vencedor.

Participantes: a guerra entre frameworks é um tema quente na comunidade JS. Backbone, Sencha e outros desapareceram. O jQuery, surpreendentemente, ainda tem uma comunidade grande. Também houve casos que não deram muito certo, como o Angular.

jQuery: o participante mais antigo. Ficou popular por corrigir a compatibilidade entre navegadores. Mas era difícil escalar aplicações com ele. Hoje em dia não é mainstream e não é a melhor escolha.

AngularJS: já está em modo LTS e foi aposentado. Foi um grande salto no ecossistema de frameworks e muita gente sente falta dele. Como não é mais mantido, não é mais um participante.

Angular:

• Surgiu para competir com o React. Por causa dos problemas de desempenho e robustez do AngularJS, muitos programadores invejavam o React. O Angular tentou modernizar o AngularJS e aproveitar as melhorias do ES6 para competir com o React.
• A curva de aprendizado pesada foi sua maior dificuldade. Exigia muitos conceitos. Herdou a curva de aprendizado do AngularJS, mas com novas dificuldades, como RxJS ou injeção de dependência hierárquica (DI).
• Outra preocupação foi o fato de ter quebrado muitas promessas. Por exemplo, a V2 permitia criar páginas com renderização no servidor (SSR) de forma simples, mas em 24/02/2022 ainda não conseguia funcionar sem JS.
• O maior problema foi a fragmentação e as atualizações de versão. Atualizar de versão era difícil demais, então os usuários não aceitavam correr o risco. Isso aparece nas estatísticas do site do npm.

VueJS:

• Foi a resposta para desenvolvedores que queriam algo com desempenho melhor que AngularJS e mais estável e fácil de usar que Angular. No sistema de templates, o Vue era muito próximo do AngularJS, mantendo a simplicidade do AngularJS enquanto ganhava força do React.
• Mas o VueJS teve problemas sérios nas versões 1 e 2. Não lidava bem com arrays, e os autores culparam o JavaScript por terem escolhido o algoritmo de atualização errado. Dependia de bibliotecas como Vuex ou Redux.
• Esse problema foi resolvido na versão 3. Porém, culpar os outros pelos próprios erros não combinava com a comunidade.

SvelteJS:

• Um concorrente em crescimento. Faz grandes promessas. Afirma que sua principal vantagem é traduzir componentes para uma linguagem imperativa. Segundo eles, isso é melhor que as declarações do React.
• É simples de usar. Mas os componentes gerados como resultado dessa tradução imperativa não são tão previsíveis quanto parecem. Em alguns casos, as mudanças não podem ser detectadas corretamente. Nesses casos, o estado pode ser corrompido e a view pode não ser atualizada corretamente. Esse problema gera muita preocupação, tornando difícil justificar qualquer projeto em SvelteJS, como já aconteceu com o VueJS no passado.

StencilJS:

• Estritamente falando, não é um framework. Permite escrever componentes e convertê-los para outros frameworks. Atualmente é possível converter para Angular, React, Vue e Web Components.
• Levanta a pergunta: isso é código parecido com o de outros frameworks? (ver original)

Mitosis:

• Você provavelmente nunca ouviu falar dele, mas foi o motivo que levou este texto a ser escrito. É o framework mais recente criado por Misko Hevery, criador do Angular.
• Tem o mesmo objetivo do StencilJS. Traduz componentes para inúmeros frameworks.
• Da mesma forma, levanta a pergunta: isso é código parecido com o de outros frameworks? (ver original)

React:

• Um dos frameworks mais antigos armazenados no repositório npm há mais de 10 anos. Mudou bastante, mas em sua maior parte continua compatível com versões anteriores. Todas as mudanças foram para melhor. Alguns dizem que fazer React com hooks tornou o framework muito melhor.
• Sua melhor qualidade não está nos hooks nem em funcionalidades visíveis, mas no contrário disso. Aplica os padrões mais recentes de JS e JSX. Isso já não é mais um framework. Talvez nunca tenha sido. O React trabalhou tanto em prol dos padrões que acabou removendo a si próprio do código do usuário.

Então o vencedor é...

• JSX. E também o React, mas mais ainda a filosofia por trás do React. O próprio React é uma biblioteca. Além disso, pode ser substituído por muitas outras bibliotecas, como Preact ou React Native. Se olhar de perto, StencilJS ou Mitosis são muito parecidos com React, e isso não é coincidência.
• "O melhor framework é o framework que se remove do código do usuário"
• O React faz grande uso de JS e JSX. O código do usuário é independente de React. Sem grandes modificações, o mesmo código pode funcionar em outros frameworks.
• Portanto, sem dúvida, o React é o vencedor da guerra dos frameworks.
• Porque não é o framework dentro do código do usuário.

[piriri11]

O importante é escrever código colocando em prática ao máximo a ideia do Tio Bob de “não se casar com frameworks”; assim, seja com React, Vue ou Angular, não daria para desenvolver de forma divertida?

[polygon]

Qual é a perspectiva do Marko JS? Como ele é apoiado pelo eBay, recentemente passei a me interessar, mas ele nem sequer é mencionado no texto original...

[minhoryang]

O "mudou bastante, mas em sua maior parte continua compatível com versões passadas" do React — eu não tive muito essa experiência de compatibilidade.
A "fragmentação e os upgrades de versão" do Angular — mas, nesse ponto, tive muitas experiências tranquilas.

[roxie]

Acho que o JSX deveria ser classificado não como framework, mas como especificação. Entendo o que você quis dizer, mas a introdução está longa demais sem necessidade e, acima de tudo, o título é clickbait. Você está usando um estilo de escrita que acaba rebaixando a qualidade do próprio texto.

[xguru]

Obrigado pelo resumo e pelos bons comentários~! Acho que esse tipo de conversa pode ajudar bastante outras pessoas ;)

[plastic041]

No geral, esse texto me parece estranho.

Primeiro, a parte sobre o Svelte.
Pelo texto original, ele diz que, ao atualizar um array, escrever algo como array[0] += 1 é um problema porque a atualização não acontece. Mas a própria documentação oficial do Svelte diz que arrays precisam ser reatribuídos para que a atualização ocorra, e, para começar, no React também não dá para atualizar um array desse jeito, certo?

O mesmo vale para a parte sobre VueJS.
Ele fala dos pontos fracos do Vue comparando com Angular, mas eu realmente não entendo qual é o sentido de colocar um código de Angular que funciona ao lado de um código de Vue que não funciona e então dizer que o Vue é ruim.

[pppqqq]

Acho que é uma crítica bem válida. A diferença entre reatribuição e mutação é algo confuso para iniciantes, e tanto o Svelte quanto o Vue usam uma sintaxe separada, embora parecida com JavaScript, então faz sentido criticar os pontos em que o comportamento não acontece como se espera.

Especialmente no Vue, o estado é atualizado quando ocorre um set por meio de proxies; à primeira vista parece fácil, mas há bastante espaço para cair em armadilhas, então também concordo profundamente com a crítica a esse ponto.

O React é bem mais livre desse tipo de problema, porque a atualização de estado não acontece por reatribuição, e sim chamando explicitamente uma função como setUpdate, oferecendo atualizações unidirecionais dentro do padrão do JavaScript. Assim, problemas como confundir a alteração de apenas parte de um array com uma reatribuição simplesmente não tendem a acontecer desde o início.

[tequila]

É uma observação meio lateral, mas no Vue 3 esse tipo de atualização de array é suportado de forma reativa, então me parece que o texto pega pesado só com versões antigas do Vue e passa por isso meio por alto...^^;; Sendo que, no React, esse tipo de atualização não funcionar de fato não é uma desvantagem pequena, mas dá a impressão de que esse tipo de característica não foi devidamente apontada, rs.

[tenshi]

Também houve muitos comentários no texto original, e muitos deles apontavam vários problemas.

[riddler]

Fiquei confuso com a parte "é um código parecido com o de outros frameworks?" com a explicação sobre StencilJS e Mitosis, então fui ver o texto original; pelo visto, a pergunta é se o código usado nesses dois frameworks não parece algo que você já viu em outros frameworks?

Acho que foi escrito no sentido de que a forma de escrever código é parecida com a do React.

[jjpark78]

A avaliação sobre o VueJS está severa demais..

A dependência de redux também não é algo da qual o React esteja totalmente livre..

Em termos de tamanho da base de usuários, é verdade que o React é disparado o número 1,

mas do ponto de vista técnico, não dá para chamar de um projeto inferior ao React.

[cckn1985]

O ponto principal discutido aqui sobre o VueJs não é mais a dependência de bibliotecas externas, mas sim a "atitude de transferir para o JS a responsabilidade pelos problemas que eles mesmos causaram"?

Acho que é verdade que a opinião pública sobre o vueJS não é muito boa.

Se você for ler o texto principal, a parte que menciona a dependência de Vuex e Redux também diz que, para resolver os problemas que surgiram no VueJS 2, bibliotecas como Vuex e Redux eram 'essenciais'.

[jjpark78]

Isso já apareceu em vários comentários no texto original, mas

quando a complexidade aumenta, tanto no Vue quanto no React, bibliotecas de gerenciamento/armazenamento em cache de estado como o Redux acabam se tornando todas "essenciais".

Pois é, no texto original isso é apontado como uma desvantagem do VueJS, e no caso do React a menção foi omitida de forma "intencional".

O comportamento da comunidade, do meu ponto de vista, não é muito importante..

[road4one]

No React, o redux não é obrigatório. Dá para fazer gerenciamento de estado usando contextAPI ou useReducer, por exemplo. Não acho, porém, que isso seja um motivo para dizer que o React é melhor que o Vue.

[cckn1985]

Sim, hehe, no geral não me parece um texto muito bom.

O autor já definiu a conclusão de antemão e está diminuindo os outros frameworks para chegar a essa conclusão.