Se não React, o que usar?
(infrequently.org)> "Frameworkism" (frameworkismo) não funciona mais. A resposta não é outra ferramenta, e sim a coragem de fazer engenharia
- Ao longo dos últimos 10 anos, mais de 100 projetos foram realizados com diversos produtos e stacks tecnológicos para web desktop e mobile
- Boa parte do tempo foi gasta resolvendo problemas de desempenho e acessibilidade causados por frameworks de frontend como React, em vez de melhorar as Web APIs
- React já é uma tecnologia legada, mas ainda assim continua sendo adotada em novos projetos
- Há quem diga que React é "moderno", mas isso não passa de repetir métodos do passado
Regra da complexidade mínima no lado do cliente
- O código do lado do servidor pode ser controlado pelos desenvolvedores, permitindo gerenciar desempenho e disponibilidade de forma eficaz
- O código do lado do cliente roda em ambientes diversos que os desenvolvedores não controlam, tornando difícil garantir estabilidade e desempenho
- A melhor estratégia é reduzir a quantidade de código enviada ao cliente
- Priorizar HTML e CSS para minimizar a dependência de JavaScript
- React e frameworks semelhantes causam duplicação desnecessária de código e degradação de desempenho
Então, qual é a alternativa?
Um debate dividido em duas perguntas
- Pergunta restrita: "Se for necessário renderizar no cliente, qual tecnologia pode substituir React?"
- Vale considerar frameworks modernos, como Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil etc.
- Ainda assim, ao usar esses frameworks, é preciso controlar com rigor o payload e a complexidade no cliente. JavaScript custa pelo menos 3 vezes mais do que HTML/CSS
- Pergunta ampla: "Como revisar por completo uma stack tecnológica dependente de React?"
- Não basta trocar por uma nova ferramenta; é preciso entender o propósito e os limites da arquitetura existente e redesenhá-la
Abordagem para a pergunta restrita
- Criar vários pequenos PoCs (Proof of Concept) para avaliar escalabilidade de desempenho e limitações
- Esses experimentos objetivos oferecem à equipe uma experiência de engenharia realmente significativa
Situação comum das equipes que fazem a pergunta ampla
- Muitas vezes há confusão nas discussões sobre substituir React
- Na maioria dos casos, as decisões foram tomadas apenas seguindo a arquitetura existente
- Falta compreensão clara da experiência do usuário e de tomada de decisão orientada por dados
Diferença entre frameworkismo e abordagem centrada no usuário
- Frameworkismo: a crença de que adicionar mais recursos ao framework resolverá todos os problemas
- Na prática, muitas vezes isso não resolve os problemas dos usuários
- Ignora padrões não convencionais ou evidências orientadas por dados
- Realismo: medir a experiência do usuário e tomar decisões com base em dados reais
- Entender as necessidades e restrições dos usuários e, com base nisso, projetar a stack tecnológica
- O ponto de partida é sempre a necessidade do usuário
Como adotar o realismo
- Uso de dados de RUM: utilizar métricas de desempenho centradas no usuário, como Core Web Vitals
- Testes de desempenho: usar ferramentas como WebPageTest (WPT) para medir os principais fluxos de usuário (critical user journeys)
- Conectar metas de negócio e experiência do usuário: usar dados para avaliar a direção das melhorias e o retorno sobre o investimento
A importância de uma abordagem orientada por dados
- Em vez de adotar frameworks com base em confiança, validar sua eficácia com dados
- Comparar os custos e efeitos reais da adoção de tecnologias por modismo
- Incentivar escolhas tecnológicas focadas na otimização da experiência do usuário por meio de métricas mensuráveis
Nada de valor foi perdido
Efeitos de políticas que impedem a disseminação do React
- Proibir React e outras abordagens centradas em frameworks contribui para reduzir custos e realinhar equipes em torno do usuário
- Mas, sem excluir completamente o frameworkismo, é difícil obter melhorias fundamentais nos resultados
- Mesmo evitando um erro, o efeito é limitado se o investimento migrar para outros erros da mesma categoria
Soluções gerais para o problema mais amplo
Centrado no usuário
- Quem toma decisões deve ser diretamente responsável pelos resultados de suas escolhas de engenharia
- Sem desculpas: se o sistema não funcionar bem para os usuários, especialmente os mais marginalizados, deve-se adotar uma versão alternativa
- Só existem problemas a resolver; fica excluída a "sacralização" de manter a forma atual a qualquer custo
Abordagem baseada em evidências
- É necessário um compromisso compartilhado com o realismo entre liderança e engenharia
- Nas decisões, a melhor evidência deve sempre prevalecer
Proteções
- São necessárias políticas para evitar as alegações fantasiosas do frameworkismo
- Ex.: exigências técnicas de progressive enhancement do Government Digital Service do Reino Unido
- As políticas podem ser ajustadas conforme o contexto da organização, como criando caminhos de escalonamento para exceções
- Mas o importante é definir critérios claros. Políticas baseadas em evidências têm forte impacto
Avaliação comparativa de tecnologias
- Não implantar um novo sistema sem principais fluxos de usuário (critical user journeys) claramente definidos
- Os principais fluxos de usuário representam as tarefas que os usuários mais executam no sistema
- Com base nisso, realizar avaliações comparativas (bakeoffs) para testar o desempenho de cada tecnologia sob restrições definidas
- Gestores de produto devem ir além de apenas sugerir experimentos: precisam definir hipóteses claras de produto e critérios de sucesso
- Isso pode ser desconfortável, mas é uma função central do gestor de produto
- Deve-se aceitar a saída de PMs que entendam que isso não corresponde ao seu trabalho
Estudo de caso
Entendendo a diferença entre realismo e frameworkismo por meio de exemplos
- Critérios para escolha de tecnologia
- A escolha tecnológica é avaliada com base no número de atualizações de dados importantes e na duração da sessão
- Algumas classes de aplicativos têm sessões longas e atualizações frequentes de dados
- Nesses casos, um modelo de dados local pode ser adequado
- Mas isso corresponde a situações raras e excepcionais
- No caso de sessões curtas
- Sites com tempo médio de sessão curto devem minimizar a quantidade de JavaScript carregada no início
- A maioria dos sites não exige arquitetura SPA
- Quando a arquitetura SPA é necessária
- A arquitetura SPA só deve ser considerada quando condições específicas forem atendidas
- Sessões longas e necessidade de várias atualizações dos mesmos dados
- Sites que não atendem a essas condições não devem adotar SPA
- A arquitetura SPA só deve ser considerada quando condições específicas forem atendidas
- Pergunta central
- A escolha não é entre frameworks JavaScript
- Na maioria dos casos, o principal é decidir se é apropriado usar ferramentas voltadas a SPA
- Para a maioria dos sites, a resposta claramente é "não"
Sites informativos (Informational)
- Estrutura ideal: HTML semântico com progressive enhancement quando necessário
- Geradores de site estático como Hugo, Astro, 11ty e Jekyll são adequados
- Para conteúdo atualizado com frequência, usar ferramentas CMS como WordPress
- Blogs, sites de marketing, páginas institucionais e sites de informação pública devem reduzir ao máximo o payload de JavaScript no cliente
- Não devem usar frameworks projetados para arquitetura SPA
- Por que marcação semântica e progressive enhancement são adequados?
- As características são sessões curtas e modelo de dados pertencente ao servidor
- A origem dos dados exibidos na página é sempre gerenciada no servidor
- Não há necessidade de abstração de modelo de dados no cliente nem de definição de componentes
- Configuração de CMS:
- Editor de baixo tráfego e alta interação para autores
- UI de visualização de alto tráfego e baixa interação para leitores
- As características são sessões curtas e modelo de dados pertencente ao servidor
Comércio eletrônico (E-Commerce)
- Arquitetura recomendada: HTML semântico gerado no servidor com progressive enhancement
- A diferença de desempenho em relação à Amazon é clara em concorrentes baseados em React
- Mais de 70% do tráfego do Walmart vem do mobile, e um Next.js baseado em SPA impacta negativamente o negócio
- Por que progressive enhancement é adequado
- Estrutura típica do e-commerce:
- Landing page com produtos disponíveis no momento e recurso de busca
- Página de resultados com filtros e comparação
- Página de detalhes do produto com mídia, avaliações e alternativas recomendadas
- Telas de gerenciamento de carrinho, checkout e conta
- Estado pertencente ao servidor:
- Manter conteúdo sempre atualizado, como preços
- Reduzir latência por meio de otimização de páginas leves
- Usar estratégias de cache agressivo, otimização de imagens e redução do tamanho das páginas
- Estrutura típica do e-commerce:
Sites de consumo de mídia (Media)
- Estrutura básica: projetar com base em progressive enhancement
- Adicionar complexidade conforme necessário, de acordo com a evolução do produto
- Por que progressive enhancement e a arquitetura de ilhas (Islands) são adequados
- Elementos interativos, como threads de comentários, podem ser compostos como modelos de dados independentes
- Podem ser implementados dentro de páginas estáticas com Web Components
- Quando SPA é adequado
- Persistência de reprodução de mídia:
- É necessário manter um miniplayer durante a navegação entre páginas
- Usar tecnologia SPA gerenciando também o limite de tamanho do JavaScript no cliente
- Suporte a reprodução offline:
- É necessária lógica para gerenciar cache local de mídia
- Vale considerar sistemas de sincronização de dados como Zero e Y.js
- Persistência de reprodução de mídia:
Mídias sociais (Social)
- Modelo híbrido: pouca interação baseada em modelo de dados pertencente ao servidor + atualizações ocasionais de mídia
- Por que progressive enhancement é adequado
- Interações comuns:
- Clique em "curtir", atualizações ocasionais etc.
- Uma abordagem híbrida com Hotwire ou HTMX é apropriada
- Interações comuns:
- Quando SPA é adequado
- Ilhas de interação profunda:
- Uso de cache no cliente para itens como rascunhos de posts
- Suporte offline:
- Entregar HTML primeiro, implementando sincronização e lógica offline via Service Worker
- Ilhas de interação profunda:
Apps de produtividade (Productivity)
- Apps de produtividade centrados em documentos têm requisitos complexos, como edição colaborativa, suporte offline e modo de visualização leve
- Modelo de dados local e arquitetura baseada em SPA podem ser adequados
- Por que SPA é adequado
- Atualizações frequentes de dados:
- Em operações como digitação e arrastar com o mouse, a lógica no cliente leva vantagem
- Necessidade de gerenciar restrições de desempenho:
- Controlar o tamanho do bundle inicial
- Aplicar estratégias de carregamento tardio de pacotes
- Atualizações frequentes de dados:
Outras classes de aplicação (Other Application Classes)
- Requisitos específicos:
- CAD 3D, editores de programação, streaming de jogos, jogos baseados na web, edição de mídia, sistemas de produção musical etc.
- Cada classe de app precisa ser avaliada com o mesmo cuidado dado aos apps de produtividade
- Requisitos para o sucesso:
- Definir os principais fluxos de usuário
- Analisar a profundidade média das sessões
- Estabelecer métricas de garantia de desempenho
- Controlar scripts e recursos críticos
Uma palavra sobre software corporativo
- "Apps empresariais" em geral causam os piores problemas de desempenho
- Dashboards, sistemas de workflow e apps corporativos de chat são exemplos típicos
- Desempenho é cultura:
- Falhar em definir e medir o tempo de carregamento inicial e o desempenho após a interação
- Uma cultura centrada no desenvolvedor que ignora o usuário é tóxica
"Mas..."
- Gestores presos a determinados frameworks, incluindo React, costumam apresentar vários argumentos para justificar essas escolhas
- Mas essas discussões não colocam a experiência do usuário no centro, e essa ausência se repete continuamente.
"...precisamos nos mover rápido"
- Pergunta: "Por quanto tempo você acha que isso vai durar?"
- Projetos baseados em NPM desenvolvidos rapidamente causam problemas de acessibilidade, baixo desempenho e aumento de complexidade, e no fim reduzem a velocidade.
- Custo de remediação: resolver problemas de JavaScript leva meses, e a velocidade de entrega de funcionalidades cai ainda mais.
- Para atingir product-market fit, é preciso priorizar acessibilidade e qualidade.
- Escolher React para "se mover rápido" acaba sendo mais caro no longo prazo e atrapalha o crescimento.
"...funciona bem no Facebook"
- A maioria das empresas não enfrenta os mesmos problemas que o Facebook.
- O Facebook também sofre problemas de desempenho por usar React, mas encobre isso com sua posição dominante.
- Empresas comuns não devem copiar cegamente o caso do Facebook.
"...nosso time já conhece React"
- Desenvolvedores React são desenvolvedores web. Trabalhar com CSS, HTML, JavaScript e DOM é essencial.
- React é a camada mais simples e substituível da stack tecnológica.
- Não há grande barreira para aprender frameworks menores e mais rápidos, como Preact, Svelte, Lit e FAST.
"...precisamos facilitar a contratação"
- O setor de TI vive hoje uma excelente oportunidade para contratar ótimos desenvolvedores.
- Conhecimento de React não pode ser critério de contratação.
- Desenvolvedores que conhecem React em geral também conseguem aprender facilmente os padrões da web.
- Sistemas mais simples, na verdade, oferecem ROI maior.
"...todo mundo usa celular rápido"
- Com o crescimento do uso mobile nos últimos 10 anos, a premissa de que recursos do cliente são baratos já é uma suposição equivocada.
- Usuários com celulares mais fracos também têm grande chance de estar entre os principais clientes do produto.
- Ao escolher React, é arriscado pressupor que todos os usuários têm dispositivos caros.
"...React é padrão de mercado"
- React não é um padrão consistente.
- A própria abordagem do React varia entre componentes de classe e componentes funcionais, uso ou não de TypeScript, escolha de ferramentas de gerenciamento de estado etc., mudando de projeto para projeto.
- A stack React é sempre mutável, e a alegação de que seria um "padrão" não passa de uma ficção reconfortante.
"...o ecossistema..."
- Há pouquíssimas bibliotecas compatíveis apenas com React, e a maioria das ferramentas também pode ser usada com Preact e outras opções.
- Todo pacote NPM funciona como dívida técnica em relação ao futuro.
- Dependências desnecessárias, como CSS-in-JS, só aumentam o custo.
"...Next.js já é rápido o suficiente"
- O Next.js traz por padrão os problemas de desempenho do React junto.
- Ferramentas HTML-first, como Astro e 11ty, oferecem desempenho melhor do que Next.js.
- Também existe o problema de lock-in a APIs de startups financiadas por VC.
"...React Native!"
- React Native torna apps mobile mais lentos e exige alto custo de manutenção.
- Usar PWA e Capacitor/Cordova é uma escolha melhor.
- O próprio Facebook está se afastando do React Native.
12 comentários
Empresas comuns não devem simplesmente seguir cegamente o exemplo do Facebook.
Há uma grande chance de que usuários com celulares de baixo desempenho também sejam clientes importantes do produto.
O React Native deixa os apps móveis mais lentos e exige muito custo de manutenção.
kkkkkkkkkkkkk kkk
O texto é longo demais e o foco do tema se perde.
Parece que o autor trata a opinião de que se deve usar React como se ela viesse necessariamente de um apego a frameworks.
Depois de dizer que é preciso sair do "frameworkismo" e abordar cada caso individualmente, ele acaba tentando criar uma receita para todo tipo de necessidade de engenharia.
Chama atenção a tentativa excessiva de monopolizar a conversa querendo responder a todas as objeções imagináveis. As contrarrespostas às objeções são estreitas demais.
Em outras palavras, o autor parece ter muita falta tanto de postura quanto de habilidade de debate para conduzir uma discussão que vá além de casos específicos e trate de princípios gerais.
Como resultado, mesmo eu não gostando de usar React, a postura unilateral do autor me fez querer ouvir um pouco mais o que pensam as pessoas que defendem seu uso.
Pessoalmente, por enquanto ainda acho que React é a melhor opção.
Entrei em desenvolvimento web na época de PHP e jQuery, e, trabalhando na empresa atual, já passei por AngularJS, Angular, React com estilo de classes e React com hooks. Do ponto de vista de quem já experimentou tudo isso, dói menos a cabeça mudar a stack tecnológica depois que os erros e aprendizados de quem usou antes já aconteceram e as bibliotecas já estão maduras. Em termos de versionamento semântico, é como usar uma versão major abaixo da mais recente. Os requisitos e as funcionalidades de alto nível não mudam, então isso não costuma ser um problema, mas quando faltam materiais de referência sobre a tecnologia de base, a produtividade realmente não vem. Além disso, pelas características dos projetos da minha empresa, diferente de um serviço SaaS, o ciclo de produto é longo e existe um período em que fazemos só manutenção, então fica ainda mais difícil adotar a tecnologia mais nova.
Talvez, se React mudar de direção para Next.js, encerrar o suporte a SPA e passar a forçar uma mudança de arquitetura, aí valha pensar novamente em uma migração tecnológica. Se Vue estivesse um pouco mais difundido, com certeza entraria na lista de opções. Não vejo motivo para não usar.
Se o RN torna os apps móveis lentos, então por que recomendar Capacitor ou Cordova? Mesmo que seja só a UI exibida de forma nativa, vejo isso como uma abordagem muito melhor em termos de desempenho do que uma web híbrida.
Infelizmente, no mercado de contratação da Coreia, se a ideia de “agnóstico de framework não cola”, há uma chance muito alta de você ser eliminado rapidamente na entrevista. Em muitas entrevistas, fazem perguntas que só quem já usou bastante determinados frameworks consegue responder.
Dev de RN chora horrores
Falando seriamente, o RN tem valor por permitir lidar com componentes nativos por meio de um bundle JS, então o caso de uso dele é completamente diferente do de um PWA.
Há partes que são difíceis de lidar até com WebView, então PWA? Acho que, no longo prazo, a direção vai acabar seguindo por aí, mas agora ainda é cedo demais. Dá a sensação de que estão fazendo uma comparação sem sentido desde o princípio.
Isso mesmo. O texto basicamente defende a ideia de que quase não há necessidade de apps nativos.
Enquanto houver pessoas atraídas pelo que é novo, esse tipo de questão vai se repetir. Como já existe um sistema feito em React, ignorar a questão de contratação não vai mudar a realidade. Há uma diferença entre o motivo pelo qual o Facebook promovia o React e o motivo pelo qual empresas comuns escolhem React depois de 10 anos.
Acho que discussões sobre mudar arquitetura e paradigma devem ser mais cautelosas do que isso e tentar convencer o maior número possível de pessoas.
Mas até o
preacté meio no estilo React, e quando você sai do ecossistema React o número de bibliotecas vai pro chão.....Se parece uma biblioteca útil, quase sempre é exclusiva para React — os desenvolvedores Vue choram
Estou usando bem e não deixa de parecer um pouco uma crítica forçada... Escrevendo de forma tão prolixa assim, passa a sensação de querer fazer parecer que estamos diante de um grande problema...
Opiniões do Hacker News
Acho que a maioria dos motivos para ser contra o uso de React está tentando resolver o problema errado. Questões de desempenho não são, na prática, um grande problema. Na maioria dos casos, melhorar o backend é mais eficaz
React e jQuery ficaram populares porque o código parece limpo. Os exemplos de código do AngularJS no início não eram agradáveis de ver
O núcleo do React é permitir renderizar de forma funcional um estado de UI O(n). No passado, era complexo gerenciar transições de estado O(n^2)
Continuam usando React porque é uma tecnologia estável e madura, como Java. A comunidade e os recursos disponíveis são abundantes
O texto do Alex mostra frustração com uma discussão que se repete. Muita gente não lê o texto até o fim
A ideia de que desenvolvedor React é desenvolvedor web parece cada vez menos verdadeira. Está aumentando o número de desenvolvedores que só conhecem SPA em React e frameworks de estilização
A maioria dos sites não precisa de SPA. Mas, para negócios que exigem muitos dados, SPA é vantajoso
Não gosto de React. Como desenvolvedor principalmente de backend, prefiro HTML gerado no servidor com um pouco de JavaScript
O desenvolvimento frontend migra para frameworks JavaScript por causa do custo de manutenção
Há muitas críticas equivocadas ao React. Desenvolvedores React conseguem concluir o trabalho sem precisar criar uma nova linguagem de template