- Hoje, a adoção do React acontece por padrão, e não por superioridade técnica, e isso está desacelerando a inovação no ecossistema de frontend
- Muitas equipes escolhem o “React que todo mundo conhece” sem considerar as restrições do projeto, criando uma situação em que os efeitos de rede passam a determinar decisões de arquitetura mais do que a adequação técnica
- Frameworks inovadores como Svelte, Solid e Qwik oferecem modelos de desempenho melhores, mas ficam para trás na disputa pelo mainstream por falta de adoção
- O React tem muitas qualidades, mas o problema é que a mentalidade de React-como-padrão aumenta o custo de oportunidade e impede considerar alternativas melhores
- Para um ecossistema saudável, diversidade e concorrência são necessárias, e a mensagem é que frameworks devem ser escolhidos com base em restrições e adequação, não como padrão
A vitória do React por padrão e seus limites
- O React já não é mais escolhido por superioridade técnica; em muitos casos, ele é adotado como padrão
- Isso reforça o hábito de equipes usarem React automaticamente, sem avaliar as restrições do projeto
- Frameworks alternativos (Svelte, Solid, Qwik), apesar de terem vantagem de desempenho sobre o React em certos cenários, não são devidamente avaliados
- Mais do que um problema do próprio React, a mentalidade de React-como-padrão está criando uma estrutura que bloqueia a inovação
O teto da inovação
- O Virtual DOM do React fazia sentido em 2013, mas hoje atua como overhead desnecessário
- Hooks resolveram problemas dos componentes de classe, mas introduziram novas complexidades, como arrays de dependência e stale closure
- Server Components e React Compiler tentam melhorar o desempenho, mas isso funciona como um remendo para contornar as limitações do modelo do React
- Já as Runes do Svelte, a reatividade granular do Solid e a Resumability do Qwik mostram um potencial muito maior com modelos completamente diferentes
Dívida técnica
- Escolher React como padrão gera custos de runtime desnecessários e a carga de gerenciar rerenderizações
- Desenvolvedores acabam gastando tempo com dependências de effects ou gerenciamento de hydration, em vez de focar no valor de negócio
- Em benchmarks, o Solid mostra desempenho de atualização 2 a 3 vezes mais rápido que o React
- Pensar centrado em padrões do React enfraquece os fundamentos da web e aprofunda a inércia arquitetural
Frameworks alternativos
-
Svelte: a revolução do compilador
- O Svelte executa a maior parte do trabalho em tempo de compilação e elimina o virtual DOM
- Os componentes ficam mais próximos da estrutura nativa da web, e o overhead em tempo de execução cai bastante
- Ainda assim, sua adoção é baixa por causa da percepção de que “há poucas oportunidades de trabalho”
- Casos como The Guardian, Wired e Shawn Wang mostram que, após adotar Svelte, houve grande redução no tamanho dos bundles e no tempo de carregamento, além de melhora na produtividade dos desenvolvedores
- Por exemplo, Shawn Wang reduziu o tamanho de seu site de 187KB em React para 9KB com Svelte
-
Solid: uma abordagem direta à reatividade fina
- O Solid combina reatividade precisa (reatividade fina) com sintaxe JSX
- Por meio de signals, ele acessa diretamente apenas o DOM alterado, evitando completamente gargalos de reconciliation
- Tem como pontos fortes o excelente desempenho e a simplicidade no gerenciamento de estado
- Os casos de adoção ainda são limitados, mas equipes pioneiras relatam grande inovação tanto em eficiência quanto em simplicidade de código
-
Qwik: a inovação da Resumability
- Em vez de traditional hydration, o Qwik tem como força a resumability, permitindo startup imediato
- Ele carrega progressivamente apenas o que é necessário no momento, e tanto estado quanto código podem ser serializados
- Mostra desempenho excepcional em sites grandes, sessões longas e redes lentas
- Muitas equipes ainda não o testaram, mas as que adotaram relatam grandes melhorias tanto no tempo de carregamento inicial quanto na eficiência de recursos
-
A complexidade da API do React e a simplicidade dos frameworks alternativos
- A API do React inclui conceitos complexos como hook, context, reducer, memoization etc., elevando a carga cognitiva para desenvolvedores
- Quando usados de forma incorreta, esses recursos aumentam muito o risco de bugs por problemas de dependência e o peso de decisões excessivamente elaboradas
- Por exemplo, a interrupção da Cloudflare em 12 de setembro de 2025 também foi causada por um erro na configuração do array de dependências de
useEffect - Em contraste, alternativas como Svelte, Solid e Qwik usam APIs muito menores e mais focadas, enfatizando simplicidade e os princípios fundamentais da web
- Os três têm vantagem técnica suficiente, mas, por causa da cultura do React como padrão, na maioria dos casos nem chegam a ser testados
A prisão dos efeitos de rede
- O domínio do React está criando barreiras que se reforçam sozinhas
- O mercado de trabalho busca apenas “desenvolvedores React”, e em cada organização bibliotecas de componentes e hábitos de desenvolvimento acabam cristalizados em torno do React
- Líderes avessos a risco naturalmente escolhem o React por parecer a opção segura, e as instituições de ensino seguem a mesma lógica
- Essa estrutura é uma característica de um ecossistema sem concorrência saudável
Rompendo os efeitos de rede
- Para sair disso, é preciso uma escolha consciente
- Líderes técnicos precisam abandonar a inércia e decidir a arquitetura com base nos requisitos; empresas podem reservar orçamento para pilotos e testar alternativas
- Desenvolvedores também devem evitar insistir em um único paradigma e aprender a lógica de vários frameworks
- Instituições de ensino precisam ampliar aulas sobre conceitos agnósticos de framework, e contribuidores open source podem fortalecer ecossistemas menores
A mudança não vem sozinha; ela precisa ser construída intencionalmente.
Checklist para avaliar frameworks
Em novos projetos, os seguintes critérios podem ser usados como base de avaliação
- Requisitos de desempenho: carregamento inicial, eficiência de atualização, tamanho de bundle e possibilidade de otimização em tempo de compilação
- Capacidade da equipe e curva de aprendizado: considerar a experiência prévia; também existem alternativas compatíveis com React, como o Solid
- Escalabilidade e custo total de propriedade: avaliar custos de longo prazo, incluindo manutenção, gestão de dependências e dívida técnica
- Adequação do ecossistema: equilíbrio entre maturidade e inovação, com pilotos em áreas não centrais e testes de ROI
Objeções comuns e respostas
- Maturidade do ecossistema: um ecossistema mais antigo não é necessariamente mais adequado para os problemas de hoje. Dependência alta de pacotes de terceiros gera efeitos colaterais como maior custo de manutenção, vulnerabilidades de segurança e bundles inchados. Ecossistemas menores, ao contrário, podem focar mais nos fundamentos da web, e com o avanço de ferramentas de IA ficou mais fácil e rápido desenvolver soluções customizadas.
- Problemas de contratação: a demanda acaba definindo o critério de contratação. É possível testar alternativas em áreas não centrais e compensar lacunas de habilidade com aprendizado prático.
- Bibliotecas de componentes: é possível reduzir lock-in e manter a produtividade com design systems independentes de framework e uso de Web Components.
- Estabilidade: o React também está em constante mudança, com hooks, Server Components etc. Em muitos casos, frameworks alternativos oferecem APIs até mais consistentes.
- Necessidade de validação em casos de grande escala: em certo momento, o jQuery também era um caso global de sucesso. O sucesso do passado não garante validade no futuro.
Os danos ao ecossistema e à indústria como um todo
- A monocultura do React desacelera o próprio avanço da web
- Talento e capital ficam concentrados apenas em resolver problemas do React, enquanto a inovação nativa da plataforma é adiada
- Instituições de ensino também ampliam o aprendizado de tecnologias pouco portáveis por causa de currículos voltados à empregabilidade imediata
- O próprio avanço da plataforma web fica bloqueado pela resposta “React basta”, e a falta de diversidade no ecossistema acaba gerando perdas para todos no longo prazo
O ecossistema desejável que podemos construir
- Diversidade é condição essencial para um ecossistema saudável
- A inovação nasce quando vários paradigmas competem e trocam ideias entre si
- Desenvolvedores crescem ao aprender diferentes formas de pensar, e a própria plataforma web evolui graças a esse espírito de experimentação
- Apostar tudo em um único framework cria um ponto único de falha. Quando ele atinge seu limite, o crescimento para e oportunidades melhores desaparecem
- Em cada projeto, a escolha deve ser guiada por restrições técnicas e adequação, sem depender apenas do React como padrão
- Só a diversidade garante inovação de verdade
- Agora é a hora de parar de plantar apenas a mesma “semente” (React) e participar da construção de um ecossistema web mais forte e inovador por meio de experimentos com frameworks mais diversos
- A escolha é nossa
19 comentários
É inevitável que desenvolvedores juniores escolham React, mas é um problema quando desenvolvedores seniores deixam de considerar outras alternativas.
É verdade que React e Java já são lixo de uma era passada, apesar de já existirem alternativas muito melhores, mas continuam dominando por tempo demais kkk
Fizeram muitos experimentos na última era caótica dos frameworks...
No trabalho, não há necessidade de jogar fora o que já vinha sendo usado e, mesmo quando é algo novo,
pouca gente concorda em abandonar o que já usava bem para aprender algo novo e migrar, e ainda existe a questão de contratação também..
Tomara que a Solid dê certo mesmo..... como é que a gente vai quebrar esse monopólio do React
Ao longo de quase 10 anos, uma infinidade de ferramentas surgiu no ecossistema de front-end; depois de passarem por ciclos de ascensão e queda, só agora as coisas começaram a se estabilizar um pouco, e aí querem tentar aquele mesmo caos gigantesco de novo...
Não é um texto enviesado demais?
"Frameworks inovadores como Svelte, Solid e Qwik oferecem modelos de desempenho melhores, mas estão ficando para trás na disputa pelo mainstream por falta de adoção"
Se não houver um critério consistente para entender o significado da palavra inovação,
a premissa já parece estar errada.
Quando vejo textos assim, fico com a impressão de que a preocupação não está em construir um produto, mas em ficar obcecado só com engenharia de software. No fim, como tudo acaba sendo mais ou menos parecido, o que importa é fazer um bom produto, mas vivem caçando novo framework e nova arquitetura, fazendo overengineering, e aí dizem que esta opção é melhor e querem trocar de novo. Acho que o importante não é o que é novo ser melhor, e sim usar bem o que você tiver e lançar o produto.
Não tem muito o que fazer, já que as big techs locais contratam com React (Next.js) como referência.
Mesmo no caso do mais consolidado
vue.js, também não há tantas vagas abertas nas big techs.Não dá para ignorar o ecossistema... a maioria das bibliotecas de terceiros e open source que surgem hoje em dia oferece suporte oficial ao React, enquanto outros frameworks ficam só com suporte da comunidade, então se você quiser combinar várias coisas e usar junto, no fim o React acaba sendo a opção mais segura...
Onde há um campo que experimenta com tanta diversidade quanto o frontend...
Graças à dedicação da equipe de desenvolvimento do Facebook com o React, os desafios no desenvolvimento de webapps aumentaram bastante. Não é vilão... pôs fim à era de PHP e jQuery.
Comentários do Hacker News
Acho que o React não virou o padrão por acaso; ele se tornou o padrão de fato por ser muito eficaz e bem projetado, e agora acabou virando o vilão
Acho bem absurda a afirmação de que o React está atrasando a inovação
No meio de inúmeros frameworks no estilo "eu também" e de projetos confusos, o React é praticamente a única opção estável e razoável
Discordo humildemente
Nunca construí apps interativos complexos com React; só fiz algumas vezes sites simples em equipes que já tinham escolhido React antes
Como resultado, o React na verdade escala mal para sites simples
Para uma página de login simples, dá para guardar o estado direto no DOM e enviar os valores só com um
<form>, e mostrar/ocultar a senha exige só um pouco de JSMas, para fazer isso em React, você precisa aprender JSX, hooks, ciclo de vida de componentes, build de desenvolvimento, empacotamento de produção etc.
Outros frameworks, como Vue ou Alpine, podem ser usados de forma "progressiva" e você pode começar na hora só com um CDN
Dizem que o React também é progressivo, mas, por causa do JSX, o processo de build/compilação é obrigatório, então não existe um jeito de começar direto por CDN na documentação oficial
Não é totalmente impossível forçar isso, mas aí você acaba enviando o compilador junto para o cliente, o que na prática é péssimo
A maioria dos sites não é do nível de Facebook, Spotify ou Netflix (e até a Netflix anunciou que está se afastando do React), então é difícil concordar com a ideia de que o React seja tão eficaz e bem projetado assim
Quando o React surgiu, 12 anos atrás, ele foi realmente inovador
Mas logo apareceram vários frameworks parecidos e, desde então, ele ficou mais no nível de "dá para usar" do que no centro da inovação
Agora ele resolve os problemas antigos do design com Virtual DOM ao custo de cada vez mais boilerplate, e fica menos atraente diante das alternativas modernas
O sentido do título do texto está invertido
Na prática, a sensação é que a "inovação" não consegue alcançar a fórmula do React (a fórmula do sucesso)
Também vale perguntar quanta inovação é realmente necessária
Na prática, repetir e melhorar costuma ser melhor e mais barato
Gosto deste texto e da visão pluralista de 2015~16
Quero dizer para a equipe "vamos fazer um pequeno caso de uso separado em Svelte", mas a checklist de avaliação acaba funcionando exatamente ao contrário do que o texto defende
Performance: em 99% dos apps ninguém percebe diferença, então no fim escolhem React
Experiência da equipe e curva de aprendizado: todo mundo só conhece React, ninguém conhece Qwik etc. Naturalmente, React
Escalabilidade, custo operacional: não há grande diferença
Ecossistema: o de React é muito maior e mais estável. React de novo
Além disso, hoje as ferramentas de IA lidam muito bem com React, e os desenvolvedores acabam aprendendo quase automaticamente com foco em React
No fim, React acaba sendo a escolha racional
Acho que web components são a saída para escapar desse oligopólio de frameworks
Todos os frameworks, exceto React, apoiam fortemente web components; a resposta é aproveitar um ecossistema compatível de componentes e utilitários sem precisar reconstruir um ecossistema próprio de React em cada um deles
Muita gente vê web components como concorrentes dos frameworks, mas na verdade eles definem a interface entre implementações de componentes e o navegador, permitindo interoperabilidade e composição confiável
Sobre essa API de baixo nível, ainda dá para inovar bastante em como criar componentes (sem build, JSX, templates, sintaxe própria, compiladores etc.) e em como compor componentes e gerenciar estado
Para superar o monopólio do React, tem que dar para dizer algo como "nosso novo framework Flugle funciona bem com qualquer framework e tem ótimas ferramentas de automação!"
Eu também uso web components com wrappers para evitar boilerplate
Com isso, consegui 80% dos recursos de web components com pouquíssimo esforço
GitHub relacionado: ZjsComponent, e também há um link para uma discussão antiga no HN (discussão no HN)
Não é perfeito, mas para mim não existe forma mais fácil e rápida de criar novos componentes HTML
Sem uma alternativa no nível de React Native, web components por si só não bastam
A tecnologia do navegador não é rápida o suficiente para chegar ao nível de apps nativos
O maior valor do React é poder unificar o desenvolvimento de GUI em várias plataformas
Já tive experiência criando apps de negócios com lit web components
Foi bem inconveniente ter que tratar todas as propriedades como
string, e não dava para comparar com bibliotecas de componentes focadas em tempo realNa nossa grande empresa, somos obrigados a usar uma biblioteca central de React nos apps internos
Não é "React por padrão"; é "só pode usar React"
A saída, na minha visão, seria reimplementar a biblioteca central em web components para permitir usar o framework que quisermos
Tenho curiosidade se alguém aqui já usou bem web components dentro de bibliotecas de UI em React
Ao criar uma biblioteca de componentes adaptada a um design system específico, tem sido satisfatório depender de bibliotecas headless como RAC
Entendo que web components podem ser complementares, mas ainda não está claro para mim onde exatamente eles são mais úteis na prática
No fim, este texto não está dizendo que React vence por performance, e sim que o "benefício social" dele é muito maior que o das alternativas, o que dificulta outras escolhas
Ou seja, concordo que o React virou a escolha padrão mesmo sem se destacar tecnicamente, e que efeitos de rede influenciam mais as decisões do que adequação técnica
Ainda assim, para as equipes, React continua tendo vantagens claras em relação às alternativas
Na prática, a maioria das equipes competentes sabe identificar muito bem quando o seu caso realmente é excepcional o bastante para adotar outra opção
Já participei de decisões de stack em várias empresas e startups, mas nunca ouvi alguém defender React com base nas "vantagens do framework em si"
A decisão sempre foi baseada em familiaridade, facilidade de contratação e ecossistema
Você está assumindo que desenvolvedores web tomam decisões racionais, mas, pela minha experiência, não é assim
As pessoas são facilmente influenciadas por vieses humanos como "prova social" e "autoridade"
Nunca ouvi alguém dizer "uso React porque gosto"
É sempre só porque "é fácil contratar"
O React tem força na resolução de problemas complexos
Mas nem todo problema é complexo, e usar uma ferramenta complexa como padrão traz complexidade desnecessária e menos flexibilidade para o projeto
A instabilidade do ecossistema que precisa sustentar recursos antigos ou futuros também não é um problema exclusivo do React
Daqui para frente, espero um novo movimento que supere o paradigma atual dos web apps
Há motivos para se preocupar com a monocultura do front-end (o monopólio do React), mas algo que me intriga é que, dez anos atrás, a situação era exatamente o oposto
Toda semana surgiam novos frameworks no HN, houve a confusão da transição do Angular 1.x para o 2.0, e o front-end era tão difícil que surgiu até o termo "fadiga de JavaScript"
Agora o React claramente se consolidou como padrão, e isso permite focar com tranquilidade no desenvolvimento do produto
Não estou elogiando o React (eu também não gosto de hooks), mas sou grato por não estarmos mais em 2015
É interessante ver como, com o passar do tempo, o clima está mudando aos poucos
Lembro da época em que havia uma quantidade absurda de bibliotecas JavaScript boutique
A consolidação do React me parece uma espécie de vitória
Acho importante tomar cuidado para não abandonar à força algo familiar e estável em nome de uma noção vaga de "inovação"
Concordo demais
De 2009 a 2015, trabalhei de forma bastante pioneira criando muitas experiências de navegador no nível de apps nativos
O forte era usar padrões web e aproveitá-los o mais diretamente possível, mas depois migrei para o back-end e acompanhei a ascensão do React de longe
React me parecia ineficiente, e a limitação do JSX de exigir que "tudo seja uma expressão" também era frustrante
Ainda assim, reconheço que o React teve um papel enorme ao trazer uma mudança importante de paradigma em gerenciamento de estado
A transição dos modelos antigos de estado para um fluxo unidirecional de dados imutáveis foi difícil, mas no fim valeu a pena
Mesmo naquela época caótica, é verdade que o React impulsionou inovação e uma grande mudança na forma de pensar o design de web apps
Mas, comparado ao SolidJS hoje, o Solid oferece os mesmos benefícios de forma mais concisa, com desempenho melhor e muito mais fácil de gerenciar
Ele também oferece melhor JSX, componentes de servidor e gerenciamento de estado reativo, e desenvolvedores React conseguem migrar com facilidade
A forma de pensar a estrutura do app é quase a mesma, então dá para ter praticamente todas as vantagens reais do React em uma versão melhor, mais rápida e com bundle muito menor
Mesmo assim, o mercado inteiro está tão concentrado em React que acabamos sendo forçados a continuar usando
O SolidJS ainda tem pontos dolorosos
O maior problema é que nem sempre é intuitivo saber se uma prop é signal ou não
O sistema de tipos também não ajuda muito
No React, se a referência muda, fica claro que quem recebe a prop vai renderizar de novo; no Solid, nem sempre está claro se a mudança será observada
Acho que a maioria das pessoas fica satisfeita em usar aquilo com que já está acostumada
Há muitos desenvolvedores que não querem usar React à força, mas no fim acabam usando o que conhecem melhor
O tempo é limitado, e é preciso fazer escolhas eficientes para sobrar espaço para família, hobbies e o resto da vida
Não é obrigatório ficar preso ao React
Na minha empresa (basicamente só eu), também temos um framework desenvolvido ao longo dos últimos 10 anos, e o publicamos como open source sob licença MIT
Link do Q.js
Gostaria de ouvir opiniões
Hooks resolveram problemas dos class components, mas também trouxeram novas complexidades, como arrays de dependência, stale closures e uso indevido
Mas esses problemas não existem só por causa de hooks; eles já existiam também na época dos componentes baseados em classes
Arrays de dependência: antes também eram comuns bugs causados por não perceber mudanças em props e state
Stale closures: o mesmo problema também acontecia com o segundo argumento de
setStateTambém havia muito abuso de métodos de ciclo de vida (
componentDidMount,componentWillMountetc.)Acho que mesmo no passado já teria sido útil uma documentação do tipo "use Effect só quando realmente precisar"
Hooks claramente ajudaram a melhorar isso porque reduzem as oportunidades de erro, tornam essas oportunidades mais visíveis e ainda emitem avisos
O problema dos arrays de dependência é muito fácil de resolver com as regras de react-hook no eslint
Usar fast-check em testes de props ajuda demais a evitar bugs quando acontecem pequenas mudanças
A comunidade JavaScript talvez pudesse passar alguns anos sem inovar
Houve inovação demais e pouco resultado prático
Agora os navegadores é que deveriam assumir a responsabilidade por um desenvolvimento de componentes razoável para a web
Se ao menos houvesse suporte no navegador para algo como um combobox com apoio de back-end ou um date picker padrão, não precisaríamos ficar reinventando gerenciamento de estado até para esses controles básicos de UI
Também acho problemático que os navegadores já não cumpram bem seu papel original
O Google tem uma influência quase monopolista por meio do Chrome, então quase nada avança nos padrões web a menos que o Google se interesse e invista recursos de desenvolvimento
Safari e Firefox equilibram isso até certo ponto, mas, para a plataforma evoluir como algo realmente diferenciado, alguém precisa assumir a liderança e empurrar
No fim, como o ecossistema JS não recebe suporte no nível da plataforma, a situação triste é que seguimos fazendo gambiarras como quem solda chips NAND
Tenho a impressão de que navegadores e CSS vêm melhorando e resolvendo de forma constante casos de uso que tradicionalmente dependiam de JS
Seria ótimo se esse movimento continuasse se ampliando
Talvez até valha pensar em dividir os navegadores em 5 ou 6 categorias, como compras, banco, social etc.
Assim, cada serviço competiria em inovação só no back-end, enquanto o front-end ofereceria uma experiência unificada, o que seria melhor para os usuários
É um desperdício enorme cada empresa continuar desenvolvendo separadamente o mesmo front-end de sempre
Uma lanchonete deveria competir para fazer sanduíches melhores, e não criar um front-end parecido para tentar roubar 8% dos usuários que instalaram o app
Na verdade, vendo o que os frameworks conseguiram fazer em cima de uma plataforma tão complexa (HTML/CSS/JS), só dá para ficar impressionado
A estrutura da web servia quando ela era focada em documentos/texto e formulários simples; hoje ela é uma base muito inadequada para apps interativos complexos
Em algum momento isso vai precisar ser completamente reconstruído
O React não venceu por ser "o melhor", e sim por ter virado o "padrão seguro"
Todo mundo conhece React, é fácil contratar, e o ecossistema é grande, então ele passa segurança
Com isso, há menos inovação, e alternativas mais leves, como Svelte ou Solid, acabam nem sendo testadas
React continua funcionando bem, mas acho que, na prática, ele é muito usado mais por inércia do que por adequação real
Concordo com a opinião do autor. Porém, a inércia de usar React não é tão errada quanto se diz. Se alternativas como Svelte, que você mencionou, forem um iPhone 17, vejo o React como algo em torno de um iPhone 15 ou 16. Pelo custo-benefício, ainda é bem utilizável e não dá para sentir tanta necessidade de trocar. No período de grande confusão no frontend, o fato de termos escolhido React, ao contrário do que o autor diz, não foi algo feito de forma consciente. Depois de usar várias coisas, o React acabou sendo escolhido porque parecia o mais utilizável. Se no futuro o React ficar desconfortável de usar e outra coisa parecer mais útil, acho que vai haver uma migração natural, sem precisar fazer um esforço deliberado para desafiar isso ou sair experimentando.
Assim como no caso da guerra dos padrões de fitas de vídeo entre VHS e Betamax, parece que ser tecnicamente superior nem sempre significa ser a escolha do mercado.
O problema do front-end não é que ele está inovando demais além do necessário?
Concordo até certo ponto.
No backend, também existe claramente o aspecto de que, quando um framework como o Spring Boot vira um padrão a ponto de até surgir algo como o e-Government Framework, a produtividade aumenta; por isso, penso que talvez o React também esteja evoluindo nessa direção.
Sim, acho que o mérito do React foi estabelecer um modelo de design baseado em componentes e um comportamento de renderização que uma maioria considerável entende. Ainda assim, o React por si só é um framework de baixo nível para criar web apps, então eu gostaria que ele ao menos oferecesse roteamento e formulários por padrão, e também fico pensando como teria sido se, no caso de state e effect, ele suportasse comparação profunda por padrão e permitisse escrever lógica apenas com estruturas de dados e funções. Por causa da limitação da comparação rasa do JavaScript, acabei escrevendo classes com a sintaxe de custom hooks.
De baixo nível... quer dizer... para implementar formulários, algo que daria para resolver só usando a tag
inputdo HTML acaba exigindo saber um monte de coisas desnecessárias, como state, JSX, componentes controlados/não controlados, além de gerar muito código, então imagino que esse tenha sido o motivo do texto.Concordo.