Existe alguém que realmente gosta de React?

 (jsx.lol)
1 pontos por GN⁺ 4 시간 전 | 3 comentários | Compartilhar no WhatsApp
  • Uma coleção curada de textos críticos sobre React e ferramentas da família React, organizada em formato de citações de vários desenvolvedores e blogueiros
  • Inclui muitos textos que apontam limitações estruturais do React, como queda de desempenho, aumento de complexidade e problemas de hidratação
  • A escolha de tecnologias centrada em React teria se consolidado mais por inércia e efeito de rede do que por adequação técnica, recebendo críticas de que a premissa de que “todo mundo conhece React” vem antes das decisões de arquitetura
  • Cresceram as preocupações com segurança e governança em torno de React Server Components e Next.js, e a CVE-2025-55182 foi divulgada como uma vulnerabilidade de execução remota de código sem autenticação com nota CVSS 10.0
  • A confusão no design de APIs, a crise de qualidade e a complexidade do ecossistema React dificultam a manutenção de longo prazo e o aprendizado, levando a debates sobre a direção do React, dos Hooks, dos recursos modernos de UI e até do fluxo de releases

Visão geral do site

  • Um site de curadoria que levanta a pergunta provocativa "Does anybody actually like React?"
  • Uma coleção cherry-picked de textos críticos sobre React e ferramentas influenciadas por React
  • Oferece assinatura via RSS

Críticas fundamentais ao próprio React

Problemas de segurança e governança

Problemas de design de API e curva de aprendizado

  • Is it Time to Regulate React?

    • O principal fracasso do React é agravado por um design de API confuso
    • A documentação é indecisa, e as discussões sobre a forma correta de usar a ferramenta nunca acabam

  • I don't have time to learn React

    • Ao contrário da alegação de que React ensina UI moderna, na prática ele quase não lida com UI moderna
    • O autofocus é quebrado, e custom elements não funcionam fora de versões experimentais
    • Para usar recursos modernos como dialog e popover, é preciso recorrer a useEffect
    • Por causa do sistema de synthetic events, quase não se aprende o comportamento real do DOM
    • Não é UI moderna, mas uma UI no nível de 2013

  • The React Blog Post: Reflections and Reactions

    • É estranho tratar todos os problemas como "skill issue" e dizer que eles se resolvem com bibliotecas externas
    • Uma tecnologia deveria permitir voltar a um projeto depois de 3 anos e ainda conseguir trabalhar nele, mas no frontend, especialmente com React, isso não acontece

  • React, where are you going?

    • Dois problemas que hoje tornam React menos prazeroso: ownership e complexity
    • Há preocupação de que novos desenvolvedores possam se sentir intimidados pelo React

Problemas de desempenho e experiência do usuário

  • Why use React?

    • Acaba-se preso por padrão ao notório padrão de hidratação
    • A estrutura faz todos os cálculos no servidor com JS, envia o HTML imediatamente e depois manda o mesmo JS de novo para o cliente

  • How React 19 (Almost) Made the Internet Slower

    • Depois de reação pública negativa e debate acalorado, a equipe do React adiou a mudança

  • An even faster Microsoft Edge

    • Houve migração de React para Web Components modernos + arquitetura HTML-first
    • Isso trouxe grandes benefícios especialmente para usuários com hardware mais modesto

  • Switching costs

    • Gostaria que houvesse mais reclamações sobre a experiência de usuário terrível imposta pelo React no client-side
    • Mas, na prática, quase todas as reclamações se concentram na experiência do desenvolvedor

  • Pivoting From React to Native DOM APIs: A Real World Example

    • Uma equipe de desenvolvimento migrou do "VDOM avassalador" do React para APIs modernas do DOM
    • A melhora em velocidade e interações foi sentida imediatamente

Problemas em mobile e plataforma

Problemas de ecossistema e comunidade

Críticas ao React Server Components

Retorno aos fundamentos e ênfase em alternativas

Casos de migração e transição

Fluxo geral e perspectivas futuras

Hooks e paradigmas alternativos

  • Why Signals Are Better Than React Hooks

    • Os Hooks do React são difíceis até de usar corretamente, e usá-los com bom desempenho é ainda mais difícil
    • Causa de queda na qualidade do código e no desempenho em muitos aplicativos

Críticas metafóricas

  • What Is React.js?

    • Vídeo que compara ao cristianismo a estranheza dos apoiadores, a excessiva seriedade consigo mesmos e a documentação interminável

Leituras relacionadas

3 comentários

 
bichi 7 분 전

React é basicamente uma religião (seita).
 
bichi 5 분 전

É tipo Ant Mill //
 
GN⁺ 4 시간 전
Comentários do Hacker News

  • Há várias coisas de que não gosto no React. React é um framework para renderizar HTML interativo na tela, não algo feito para programação extremamente complexa
    Primeiro, ele depende demais de conceitos e terminologia complicados. Comparando com Vue, useEffect corresponde a watch, e useMemo a computed
    Segundo, esse jeito “inteligente” desnecessário foi além da terminologia e contaminou o ecossistema. Antigamente, no Redux, até para incrementar um único número era preciso escrever muito código em vários arquivos, e parecia que isso acontecia porque o autor gostava de conceitos espertinhos de ciência da computação. Na mesma época, no VueX, bastava simplesmente incrementar esse número. Felizmente, hoje o ecossistema React tem vários gerenciadores de estado mais sensatos
    Terceiro, o React não oferece uma ferramenta de trabalho com CSS por padrão
    Quarto, o React não faz otimização automaticamente. É preciso saber quando e como usar ou não usar useEffect e useMemo, e também existe muito folclore sobre otimização em React. O problema é que isso acontece apesar de rerenderização ser justamente o objetivo central. No Vue, o framework leva você a usar as próprias ferramentas dele e faz a maior parte das otimizações ali dentro, então nunca pensei que precisaria otimizar manualmente um app em Vue
    Quinto, esse próprio folclore é um problema. A API do React e a “forma correta de escrever React” mudaram grande e repetidamente tantas vezes que ainda hoje é muito difícil separar o que continua válido do que não é mais
    No fim, dá para resumir dizendo que o React foca demais em ideias, ciência da computação e abstrações de alto nível, e menos em facilitar de fato renderizar HTML interativo na tela
    Uso bastante React, Vue e Svelte, mas quando uso React fico tendo que me preocupar o tempo todo com coisas que Vue ou Svelte já teriam resolvido. Em termos de desempenho, os três são parecidos
    Já escrevi sobre isso antes: https://www.brachkow.com/notes/what-i-like-in-vue/

  • Tendo passado por praticamente todas as grandes fases do JavaScript nos últimos 16 anos, em certo sentido eu gosto de React
    React é o pior framework JavaScript, excluindo todos os outros que já tentamos
    Eu escolheria React qualquer dia em vez da era do Angular 1. Preferiria o MVC pesado do Angular 1 a algo como Backbone, em que você montava tudo manualmente do zero toda vez, e a estrutura MVC mínima do Backbone era melhor do que a sopa clássica de JQuery. Naquela época, eu também teria escolhido na hora a manipulação de DOM e a biblioteca padrão ampliada do JQuery em vez das APIs nativas
    React também tem seus trade-offs, mas chegamos até aqui depois de passar muito tempo tentando inúmeras alternativas que simplesmente não funcionavam

    • Gosto de usar React e escolheria React em vez das opções anteriores. Mas, se isso é tudo de que preciso, eu não escolheria React em vez de htmx/data-star e renderização no servidor, e isso continuaria valendo mesmo se houvesse algumas páginas um pouco mais complexas
    • Mas não entendo por que React em vez de Vue. Minha maior frustração era que, no fim, o Vue acabava se movendo na direção do React. A estrutura original de componentes do Vue, com template HTML, estado em JavaScript e estilo em CSS juntos, era realmente ótima. A forma de buscar dados por URL dentro do componente também era muito intuitiva
    • Concordo. Passei de HTML em cgi-bin escrito na mão para JQuery, Angular v1 e React, e React é uma ferramenta que eu pegaria com gosto. Ele faz o que eu preciso fazer
    • Prefiro React a Angular, e prefiro Vue a React
    • Fico curioso se já usaram Svelte. Não entendo muito bem por que alguém poderia preferir React. Na minha visão, a única vantagem do React é que ele é como a IBM do frontend. Ninguém foi demitido por escolher React

  • Claro que existem pessoas que gostam de React. Não é algo que, como JavaScript, você seja praticamente obrigado a usar, e ninguém é forçado a usar React ou outro framework web, mas o React venceu. Dá para ver isso como evidência de que, pelo menos, as pessoas gostam dele o suficiente em comparação com a maioria dos outros frameworks
    Até o fim dos anos 2010, uma reclamação comum sobre desenvolvimento web era que tudo mudava rápido demais e sempre surgiam coisas novas para aprender, e essa reclamação era válida. Mas, quando a monocultura do React chegou ao topo, agora todo mundo reclama disso também. Não dá para vencer nunca

    • No trabalho, quase nunca pude escolher frameworks e bibliotecas. Quase sempre eu estava dando continuidade a algo iniciado por outra pessoa anos antes, ou preso a uma organização com escolhas bem rígidas. Pessoalmente, eu não escolheria React
      O React venceu porque virou a opção padrão e porque as pessoas gostam daquilo com que já estão acostumadas
    • React tem suas vantagens, mas também tende a ser escolhido por inércia mais do que por ser a melhor ferramenta para o trabalho. Entram razões como “todo mundo usa React, então podemos maximizar o pool de contratação e de terceirização” e “um projeto em React fica bem no currículo”
    • Na prática, você acaba sendo forçado a usar React e Next.js. Muitos fornecedores de SaaS fazem parceria com a Vercel e deixam pontos de extensão abertos só para esse lado
      Se você quiser usar outra coisa, precisa implementar as integrações por conta própria, encontrar algum projeto open source que já tenha feito isso ou perguntar para uma IA
      Em projetos paralelos até dá, mas no ambiente de trabalho isso é difícil de imaginar
    • Não entendo o que significa dizer que ninguém é forçado a usar React. Onde fica esse admirável mundo novo em que você aprende Lisp, usa isso em tudo o que quiser, e a cultura corporativa não influencia em nada a escolha de tecnologia?

  • Gosto de React. Também já usei com seriedade o ecossistema HTMX/Hotwire
    Quando a navegação viesse da caixa de entrada, eu queria um botão de voltar que usasse a API do navegador para voltar; caso contrário, queria mandar para um link da caixa de entrada para preservar o scroll. Para isso, eu precisava ligar o comportamento no HTML para chamar a função de voltar e, no controller, determinar a página anterior e então entregar um botão de voltar com JavaScript habilitado ou um link fixo. A lógica ficou espalhada em 3 arquivos
    No React, o JavaScript dentro do componente pode determinar se a página anterior era a caixa de entrada e, com base nisso, mostrar o JSX do botão de voltar ou um link. Tudo termina em um arquivo só. Para mim, basta modelar uma única entidade conceitual, enquanto nas outras abordagens eu precisava enfiar a funcionalidade à força em 3 entidades
    É mais lento? Com certeza. Ainda assim, me deixa feliz. Se você sofre com o codebase bagunçado de React da empresa, tem que culpar seus colegas. Sem React, certamente teria sido pior

    • É por isso que odeio apps de página única em React. Eles sempre parecem encontrar um jeito idiota de quebrar o botão de voltar e os controles de navegação do navegador
      Tirando um aprimoramento ocasional de formulários, eu sempre preferiria htmx/renderização no servidor e comportamento nativo
    • Acho que HTMX é melhor usado só para trabalhos relacionados a estado de dados. Coisas que não dependem do estado do recurso, como um botão de voltar inteligente, é melhor não calcular no backend
      No estilo recomendado do htmx, bastaria conectar um botão onclick a um JavaScript inline ou, se você não gostar disso, chamar uma função como goBackOrInbox
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      Se você usa muito esse padrão, dá para parametrizar passando como argumento o caminho para onde deve ir
    • Acho que a melhor forma de resolver o problema do botão de voltar é não complicar demais e garantir que só entre no histórico do navegador aquilo para o qual você realmente quer voltar. A própria formulação do problema parece gritar: “se você estruturar melhor, isso vira um problema que nem precisa ser resolvido”
    • Pode haver partes complicadas aqui e ali, mas imagino que também daria para fazer isso com Web Components

  • Usei código React por muito tempo e agora estou trabalhando em um grande projeto Vue na empresa. Antes, todo mundo dizia que Vue era a escolha mais fácil e acessível entre os dois, mas agora comecei a ver diferente
    React é elegante porque, no fim das contas, componentes são basicamente só funções, e fora isso não tem muita coisa. Deixando o ecossistema Next.js de lado, é a coisa mais elegante que já vi em desenvolvimento frontend
    Já Vue me parece uma mistura confusa. Dá para ver os traços de desenvolvedores backend que não queriam aprender JavaScript direito, adotaram e exaltaram a ferramenta, e o resultado parece uma mistura estranha que não se encaixa de forma limpa

    • Nunca entendi muito essa visão. Componentes React não são apenas funções, e sim funções com um contexto injetado magicamente acessado por hooks. Esses hooks exigem vários tipos de garantia, e se você não tiver isso em mente acaba tendo resultados difíceis de depurar. Para mim, isso está longe de ser elegante
      Já usei todos os principais frameworks e hoje estou criando uma grande aplicação web em Angular. No Angular, componentes são expressos como classes, templates e estilos. Event listeners em geral chamam métodos da classe, e o estado pode ser tão simples quanto propriedades da classe. Parece muito mais natural e tem bem menos armadilhas. Claro, não zero
    • Fico curioso sobre há quanto tempo você usa Vue. Também tive uma impressão parecida alguns anos atrás, olhando para Vue a partir de um background em React. Mas hoje prefiro Vue a React, e escolho Vue primeiro tanto para projetos pessoais quanto para projetos de trabalho
      A experiência de uso é um pouco diferente. Há coisas mais fáceis no React e outras mais fáceis no Vue, mas o fato de o Vue usar signals é uma grande vantagem para mim

  • Mais do que o React em si, tenho mais interesse, de forma geral, na pergunta qual é a melhor maneira de escrever UI em código
    Sou fã de React e uso React em quase todas as aplicações web que crio, mas o maior e mais claro problema é que escrever UI com React não parece tão natural quanto escrever ferramentas de linha de comando em Go ou apps em tempo real em Elixir
    Algumas linguagens são surpreendentemente naturais e sem atrito para certos tipos de tarefa. Mas UI ainda é algo que ninguém conseguiu dominar de verdade. Swift, JSX/HTML, Svelte, ou qualquer framework popular dessa linha, todos passam a sensação de estar contornando o problema até certo ponto. Parece que, em algum momento, os designers da linguagem/framework acabaram colocando uma sintaxe improvisada, estranha ou dolorosa para acomodar os requisitos
    A interface natural da UI é visual, então ferramentas como o Figma podem ser uma parte importante da solução. Ainda assim, parece que falta alguma coisa. Deve existir uma forma mais intuitiva de expressar em código algo visual. As soluções atuais são difíceis de definir com precisão, mas sempre parecem ficar por um triz aquém do ideal

    • Tenho uma sensação parecida. Quando o React surgiu, eu realmente gostei porque, em comparação com as alternativas da época, ele parecia perfeito
      Ainda hoje prefiro React a quase tudo, incluindo Svelte, Vue e Solid. Mas recentemente comecei a usar Crank(https://crank.js.org/) e ele parece um passo mais perto da direção para a qual eu quero ir. Ainda assim, até agora só usei em projetos de brincadeira, então é difícil dizer o quanto escala bem tanto em performance quanto em experiência de desenvolvedor
    • Concordo fortemente com a ideia de que “algumas linguagens são surpreendentemente naturais e sem atrito para certas tarefas, mas UI ainda é algo que ninguém conseguiu dominar de verdade”. Se você olhar os livros[1] do começo dos anos 90 que tratavam desse problema, isso ainda se aplica exatamente hoje
      A melhor análise que já vi até agora está em “Programs = Data + Algorithms + Architecture: consequences for interactive software engineering”, de Chatty[2]. É um pouco difícil de ler, mas vale muito a pena
      Resumindo rapidamente, o problema é a arquitetura e, mais especificamente, o desalinhamento entre linguagem e arquitetura. O estilo arquitetural de chamada/retorno induzido por linguagens de programação “de propósito geral” não combina com a arquitetura necessária para interfaces de usuário; na verdade, entra em conflito com ela
      Também escrevi sobre esse tema em “Can Programmers Escape the Gentle Tyranny of call/return?”
      A abordagem atual é primeiro criar Objective-Smalltalk[4], uma linguagem de programação que permite expressar facilmente estilos arquiteturais alternativos
      Com isso, agora estou criando um framework de UI chamado interscript, que também inclui HTMXNative e vários elementos adicionais
      Parece estar funcionando muito bem
      [1] Ex.: Myers et al., “Languages for developing user interfaces” https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • Como engenheiro, é fácil olhar para todo problema e pensar: “existe uma solução perfeita, eu só ainda não a encontrei”
      Mas, com o tempo, passei a aceitar respostas menos idealistas. Talvez essa solução nem exista. O espaço do problema pode ser complexo demais, e talvez não exista uma solução geral humanamente viável que cubra todas as formas possíveis. Se existe uma área em que isso provavelmente é verdade, é UI

  • Sim. O React é, de longe, a interface mais intuitiva, combinando com sucesso estilos declarativos e imperativos. Entre todos os frameworks de UI em todas as linguagens, não vejo nada que chegue perto de JSX

    • Muitas outras plataformas, como Flutter, SwiftUI e Jetpack Compose, vêm implementando React como se fosse o framework de UI delas
    • Se é tão intuitivo assim, então não sei por que quase todo app em React acaba com bugs de performance

  • Gosto muito de Svelte e uso SvelteKit para apps mais complexos
    Senti que foi uma melhoria muito melhor em muitos casos em que antes eu teria usado React
    O Svelte parece muito mais fácil de aprender para quem conhece os fundamentos de desenvolvimento web, HTML, CSS e JavaScript. Mas hoje em dia vejo muita gente começando desenvolvimento web por React, e isso parece meio invertido
    Pessoalmente, estou criando apps mobile com SvelteKit + Capacitor, e escrevi a configuração aqui: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    Para landing pages simples, prefiro Astro

    • Eu também sempre pego Svelte + SvelteKit primeiro. Usar Kit em apps simples pode ser exagero, mas é bom ter quando a coisa fica inesperadamente complexa
      Concordo que hoje em dia as pessoas começarem desenvolvimento web por React parece invertido. O Svelte evita bem esse problema ao tratar HTML como língua materna. Se você começar desenvolvimento web com Svelte(Kit), é bem provável que aprenda mais fundamentos do que começando com React
    • Para mim, a combinação Svelte + Astro é a certa. É ótima para sites de documentação e páginas com interatividade opcional

  • Tenho viés porque fui uma das pessoas que ajudaram a tornar o React possível, mas eu realmente adoro React. Antes dele, eu tentava de tudo para consertar os problemas que enfrentávamos no frontend. Mas, depois que o React apareceu, essa necessidade desapareceu, e eu pude simplesmente focar em construir

  • Uma das apresentações de que realmente gostei foi https://www.youtube.com/watch?v=h9SDuTSy7ps. Pela minha experiência, a arquitetura do React é realmente muito boa e combina bastante com a criação de aplicações grandes
    Infelizmente, o maior problema do React é que ele te força a entrar no ecossistema JS/TS. Para mim, JavaScript/TypeScript está sem dúvida mais para alvo de compilação do que para um sistema com o qual eu queira lidar diretamente
    Estou satisfeito com Elm. A comunidade é realmente pequena e, às vezes, você precisa criar suas próprias bibliotecas. O TEA às vezes parece pouco natural para quem vem de React, mas eu sempre fico animado ao trabalhar com Elm porque não preciso me preocupar com estados implícitos e inesperados como useEffect
    Além disso, o Claude parece aguentar melhor Elm do que React, pelo menos dentro de codebases grandes e assustadoras

    • Pela minha experiência, Elm está praticamente morto. Acho melhor usar React com TypeScript, que tem bibliotecas que continuam funcionando. Também já houve tentativas de tornar possível compilar TypeScript para nativo
    • Gosto de TEA, mas nunca entendi completamente como isso escala em apps com componentes reutilizáveis ou páginas suficientemente complexas. Fico curioso se existe uma forma consensual de lidar com isso
      Como estado parece ser um grande tabu, isso também parece um pouco conflitante. Também fico me perguntando se isso significa que todo app em Elm acaba virando um app com Redux global + React sem efeitos. Queria entender melhor o que é divertido no Elm e como vocês trabalham com ele. Links também são bem-vindos