- Uma discussão que compara o Backbone do início dos anos 2010 com o React de 2025, revisitando o quanto o frontend realmente avançou em 15 anos
- O React parece enxuto e moderno na superfície, mas internamente finge simplicidade por meio de camadas de abstração complexas
- O Backbone tem código mais verboso, mas o fluxo de eventos e a manipulação do DOM são explícitos, então até desenvolvedores iniciantes conseguem rastrear facilmente o funcionamento
- No React, por causa de gerenciamento de estado, arrays de dependência e problemas com closures, a depuração se torna difícil se você não entender o funcionamento interno
- No fim, ao retomar a essência de “evento + estado = UI”, o texto levanta a necessidade de um novo modelo com simplicidade e uma estrutura hackable
O progresso de 15 anos
- Um exemplo de campo de senha escrito com um framework dos anos 2010 (Backbone) e outro com React, desenvolvido por mais de 10 anos
- As duas implementações têm tamanho parecido e a mesma funcionalidade
- O React contou com incontáveis horas de trabalho de desenvolvedores e com o suporte de um ecossistema enorme
- Ainda assim, o autor aponta que é mais interessante perguntar não “o quanto o React melhorou”, mas “o quanto ele avançou tão pouco”
- O React oferece a ilusão de simplicidade na aparência, mas na prática é difícil de entender por causa de abstrações complexas
- O Backbone expressa de forma explícita o fluxo simples de disparo de evento → execução do handler → geração de HTML → inserção no DOM
- Já o React esconde o funcionamento interno e, ao sair de exemplos simples, surgem problemas que só podem ser resolvidos entendendo os mecanismos internos
A ilusão da simplicidade (The Illusion of Simplicity)
- O código em React parece limpo, mas isso é resultado de trocar a simplicidade explícita por complexidade abstrata
- O Backbone é verboso, mas mostra com clareza “o que acontece e quando acontece”
- Até desenvolvedores iniciantes conseguem acompanhar facilmente o fluxo do código
- No React, o estado interno e a lógica de renderização ficam escondidos, então bugs inesperados acontecem com frequência
- Exemplo: se a
key de um item de lista for trocada para o índice, o React entende como outro componente e reinicializa o estado
- Se
value mudar para undefined, ocorre uma transição de componente não controlado para controlado, o que faz o valor do input ser resetado
- Ao usar
useEffect, também é comum surgir loop infinito
- Se o array de dependências incluir um objeto recriado a cada renderização, o React entende isso como mudança
- Para evitar isso, é preciso usar
useMemo e useCallback para estabilizar identidades (stabilize identities)
- Isso traz a carga de ter que se preocupar com conceitos que antes não precisavam ser considerados
- Também existe o problema de o handler de clique referenciar estado antigo (stale state)
- Porque a função captura o estado no momento em que é criada
- A solução é colocar o estado no array de dependências ou usar atualização funcional, como
setState(x => x + 1)
- Mas ambas as abordagens passam a sensação de serem apenas um quebra-galho (workaround)
O preço da mágica (Magic Has a High Price)
- Esses problemas não são casos excepcionais, mas questões comuns que aparecem com frequência em apps de porte médio ou maior
- Para depurar, é preciso entender o algoritmo de reconciliação (reconciliation algorithm), a fase de renderização (render phase) e o scheduler (batch update)
- O React é uma estrutura que “funciona mesmo sem você saber por quê”, mas quando surge um problema, só dá para resolver entendendo o interior
- A complexidade é tanta que existe até a ideia de que “para realmente entender React, você precisa implementá-lo por conta própria”
- Existem tutoriais como “Build your own React”
- Mas o fato de ser necessário entender virtual DOM, prioridade de agendamento e renderização concorrente para criar um simples validador de senha traz uma implicação crítica
- Backbone e jQuery têm uma estrutura honesta e hackable
- Você pode olhar o código-fonte diretamente e modificá-lo
- Como são baseados em métodos do DOM, são fáceis de entender e expandir
- Já as camadas de abstração do React dificultam o acesso e a modificação do interior
Qual é o próximo passo? (So, What's Next?)
- No fim, tanto React quanto Backbone são tentativas de resolver o mesmo problema: “evento + estado = UI”
- Em apps grandes, a complexidade do React pode ser justificável, mas para a maioria dos apps pequenos e médios ela é um peso excessivo
- É necessário um novo modelo de UI com simplicidade e transparência
- Um sistema sólido como o DOM, mas intuitivo
- Uma estrutura voltada a ser imediatamente compreensível e modificável, como Backbone ou jQuery
2 comentários
Em apps de pequeno e médio porte, parece mais adequado se preparar para o futuro projetando classes em JavaScript, em vez de usar Backbone ou jQuery.
Ter que decorar novamente os templates do jQuery ou do Backbone para seguir em frente parece um retrocesso.
Comentários do Hacker News
Já usei Backbone, Angular 1, Ember e React
Não dá para ignorar por que o React ficou popular. Em composição de componentes, tratamento de eventos, gerenciamento de estado e atualizações eficientes do DOM, o React resolveu problemas crônicos dos frameworks anteriores
No Backbone, gerenciar o ciclo de vida do DOM era complicado, e ter que definir handlers de evento como strings dificultava a manutenção. O React simplificou esses problemas com fluxo de estado unidirecional e DOM virtual
Hoje, se eu quisesse usar JS puro, acharia uma solução de templates como lit-html muito melhor do que Backbone
O frontend era complexo antes e continua complexo agora, mas hoje dói muito menos
A complexidade de um app não vem da quantidade de componentes, e sim do gerenciamento de estado
Eu frequentemente enfrentava travamentos de UI por causa do fluxo de dados bidirecional do Backbone Store. A inovação do React foi a arquitetura Flux centrada em fluxo de dados unidirecional
Acho que um bom framework é uma ferramenta que naturalmente te leva ao “Pit of Success”. O React cumpriu bem esse papel
Por exemplo, problemas como stale closure, loops infinitos de useEffect e reset de inputs por mudança de chave não existiam no Backbone
Os problemas do Backbone eram visíveis e fáceis de depurar, mas os do React ficam escondidos atrás da abstração
Como a maioria dos apps não está na escala do Facebook, uma abordagem explícita e simples pode acabar sendo melhor
Afirmar categoricamente que uma tecnologia popular é “ruim” parece uma espécie de arrogância ingênua
Claro, popularidade não garante qualidade, mas é exagero achar que engenheiros brilhantes do mundo inteiro foram todos enganados
Se grandes empresas e marketing empurram, CTOs adotam, e quando a carreira está em jogo ninguém quer dizer “isso é ruim”. Popularidade ≠ adequação
O React não venceu só por superioridade técnica, e sim também por marketing do Facebook e autorreforço do ecossistema
Mesmo depois de 15 anos, o tamanho e a complexidade do código não diminuíram tanto assim. Só ficaram complexos de outra forma
Olhar para o passado não é nostalgia; é uma forma de verificar se adicionamos complexidade desproporcional
A web ainda parece uma fronteira selvagem de padrões de design. Depois que aceitei isso, fiquei mais tranquilo
No fim, cada projeto precisa reavaliar os trade-offs
A afirmação “para coisas simples você não precisa de React” é uma comum falácia do React
Avaliar React por exemplos simples é como “avaliar uma linguagem pelo tamanho do Hello World”
O motivo para usar React também em coisas simples é que ele é usado em coisas complexas. Um conjunto de ferramentas consistente favorece a manutenção
O Backbone era “algo que parecia framework, mas na prática era um amontoado de código de cola”
A verdadeira vitória do React foi permitir não precisar manipular o DOM diretamente e ter gerenciamento de estado reativo. Essas duas coisas aumentaram muito a produtividade no desenvolvimento
Link de um tutorial antigo, versão arquivada
Hoje me interesso mais por como os LLMs entendem código. Sintaxe declarativa como JSX é amigável para LLMs
Mas o React depois do useEffect parece ter ficado mais nebuloso em expressividade e explicitude
Fica bem claro por que o React se tornou tão popular
O código React é em sua maior parte JS puro e HTML, e o núcleo é basicamente só
useState. É intuitivo, dá para entender até sem documentaçãoO Backbone dependia de seletores em string como
.space-y-2, e isso transformava manutenção em inferno. Se você mudasse um nome de classe, metade do app quebravaO React resolveu esse problema estruturalmente
O código Backbone deixa claro “o que acontece e quando acontece”, mas no React é preciso entender o funcionamento interno
Eu também li várias vezes o guia do useEffect do Dan Abramov e o blog do Mark Erikson para entender o timing do React
Mesmo vendo código Backbone de 10 anos atrás, eu entendia na hora
Há 6 anos mudamos o time de Backbone para Angular
O Backbone era intuitivo e sem mágica, então era bom para juniores, mas no fim TypeScript e Angular eram mais sistemáticos
Hoje usamos NG20 e estamos satisfeitos. Se um dia os navegadores passarem a oferecer mais recursos por padrão, talvez possamos voltar a um estilo mais simples
Estamos sempre programando sobre abstrações
O importante é se essa abstração traz ganho de produtividade frente à complexidade e se ela é confiável
Mesmo no pior caso, precisa ser possível depurar
No React, o campo de input lida com Undo de forma mais natural do que no Backbone
No Backbone ele desfaz letra por letra, mas no React desfaz por palavra