Falo sobre uma aparente mudança de atitude em relação ao React na comunidade e também faço algumas recomendações sobre a tomada de decisões para seus projetos.
Parece que o React está sofrendo um pouco recentemente, o que não sou 100% contra, mas não consigo enfatizar o suficiente o quão arraigado o React é. É o que acontece quando um framework ou biblioteca é o tema quente por mais de uma década!
Acabei de ler “Remover o React é apenas um ponto fraco ao sair da sua base de código”. Eu realmente não concordo com alguns dos sentimentos do artigo, mas gosto de como o autor referiu preocupações sobre o que aconteceria se um grande player de framework como Vercel fosse embora. Essa é uma realidade importante e preocupante. Não estou 100% convencido de que React é sempre uma fraqueza, especialmente quando você aplica um pouco mais de nuances.
Vercel está por trás do Next.js, que é sem dúvida o framework React mais popular que existe. Acho que é importante para mim que eles não desapareçam porque a recente queda da Netlify teve um impacto tangível não apenas na comunidade da web, mas também em nossos clientes – alguns dos quais estão agora embarcando em projetos de re-plataforma, incluindo mudando para Next.js. Pela nossa experiência, o Netlify simplesmente não tem sido bom o suficiente para grandes projetos.
É sempre uma preocupação que a sobrevivência da tecnologia dependa de empresas financiadas por capital de risco, mas isso é assunto para outro dia. Uma coisa que isso definitivamente faz é criar uma base frágil para a web.
Bibliotecas e frameworks podem ser muito úteis em projetos complexos
Isto é especialmente no caso de projetos que exigem uma gestão estatal muito complicada. Isso é algo muito difícil e confuso, tanto com componentes da web quanto com JavaScript nativo. Atualmente, pelo menos.
Um sonho meu é o estado reativo nativo — tanto global quanto local — em componentes da web que não requer seleção e manipulação de DOM. Isso é algo que gosto muito no React e no Vue. O problema é que você obtém um bom gerenciamento de estado com estruturas, mas também pacotes enormes de JavaScript no lado do cliente como um sintoma disso. Torna-se uma experiência do desenvolvedor que supera a situação da experiência do usuário. Nada bom.
Vejo muitas coisas estranhas e maravilhosas trabalhando no atendimento ao cliente. Nos mais de 15 anos em que venho trabalhando com clientes — com breves passagens por equipes de produto — nunca vi a mesma configuração de projeto. É claro que já vi sites simples, superprojetados com bases de código baseadas em React, mas também vi o inverso: sistemas muito complicados, costurados com um SSG, Nunjucks e componentes web que, francamente, são um pesadelo para manter e melhorar. A decisão incorreta foi provavelmente tomada no início destes projetos e provavelmente também foi cobrada dívida técnica dispendiosa.
Se você quiser meus dois centavos: o React não vai a lugar nenhum por muito tempo. Não uso as grandes empresas de tecnologia como barômetro para essa opinião porque as grandes empresas de tecnologia representam uma pequena porcentagem da indústria geral. Eles são apenas mais barulhentos do que todos os outros.
A principal razão pela qual acho que o React não vai a lugar nenhum é porque – embora seja um participante minoritário na indústria – ainda existem milhares , senão milhões de bases de código que são fortemente baseadas no React.
Eu gosto dessa realidade? Não especialmente, não, mas eu meio que superei isso agora. Não gosto do fato de bibliotecas como React serem tão usadas, mas com o passar dos anos, fiquei mais empático com a decisão das equipes de usá-las. A plataforma web atualmente não nos fornece todas as ferramentas de que necessitamos, mas tenho esperança de que isso acontecerá no longo prazo. Também entendo que as pessoas mal podem esperar por isso e precisam se mexer, então as bibliotecas atendem às suas necessidades melhor do que a plataforma web atualmente.
Parece que o React lançará uma versão 19 de seu framework. Ainda hoje descobri que eles oferecerão suporte a elementos personalizados – também conhecidos como componentes da web, que são solicitados há mais de 6 anos neste momento. Será interessante ver como isso funciona porque acho que poderia ser uma configuração decente: reagir para fazer todas as coisas complicadas de estado e componentes da web para fazer a renderização das coisas. Na minha opinião, será muito mais fácil abandonar o React. Ótimo para sistemas de design também.
O que você deve usar em seu projeto então?
Sinceramente, não consegui responder a isso. Antigamente eu teria twittado que o React não deveria ser usado em nenhuma circunstância, mas na época, eu só tinha visto bases de código realmente sombrias e complicadas alimentando contextos muito simples. A cultura do discurso do React também era extremamente tóxica (às vezes ainda é) e eu não queria apoiar isso de forma alguma. Porém, mais alguns anos depois, vi muitos projetos muito complicados, com pouca capacidade, com uma tentativa corajosa de não usar estruturas de qualquer tipo.
É tudo uma questão de compensações no mundo real. Quais recursos você tem internamente? Quais são as necessidades de desempenho do seu projeto? Você está com um prazo difícil? Você quer atrair um determinado tipo de desenvolvedor, com um determinado conjunto de habilidades para sua equipe no longo prazo? Quem você excluirá ao escolher FrameworkX ou FrameworkY? Você se opõe à fonte de financiamento de uma estrutura? Que danos uma tecnologia causa aos seus usuários?
Muitas perguntas que deveriam ser feitas em vez de “FrameworkX está na moda no momento: vamos usar isso”.
Tudo o que eu diria é que encontrar a solução de menor tecnologia e aproveitar ao máximo os recursos do navegador é uma boa maneira de construir algo resiliente e confiável. Além disso, evitar fazer o máximo possível de renderização (e re-renderização) do lado do cliente geralmente também melhora as coisas para todos. Gosto de como o Astro faz isso com as Ilhas, por exemplo. Também entendo que isso não é possível em alguns projetos.
Cada projeto é diferente e cada equipe tem seus próprios problemas que precisam resolver. Meu conselho geral é gastar muito mais tempo planejando e criando estratégias como você já está fazendo e sempre pensar “qual é a pior coisa que pode acontecer?” junto com “quem vamos prejudicar com esta decisão?”. Funciona muito bem para nós. O planejamento é muito mais profundo do que dividir os projetos em tickets do Trello no final do dia.
Mais importante ainda, não baseie as decisões do seu projeto no que algum cara pensa no Twitter, no Mastodon ou no blog deles. Isso inclui minha opinião também, porque não entendo o seu projeto, a menos que você me traga para ajudá-lo. Somente você e sua equipe fazem isso e são essas opiniões e conhecimentos que realmente importam. A comunicação eficaz é o verdadeiro código de trapaça.