Você vai a uma reunião de planning e o PM solta a frase de sempre: "o backend é o complicado, o frontend a gente monta rápido no final". Ninguém discute. O tech lead concorda com a cabeça. E aí, se você já passa dos cinco anos montando interfaces de verdade, alguma coisa se aperta no seu estômago, porque você sabe exatamente como essa história termina: com um estado global que ninguém entende direito, com uma decisão de rendering tomada sem pensar que agora custa caríssimo reverter, com uma UI que desaba sob o próprio peso três sprints depois. O desenvolvimento frontend deixou de ser sobre organizar caixas e escolher uma paleta de cores faz tempo, e mesmo assim continuamos planejando como se ainda fosse 2014.
O desenvolvimento frontend nunca foi sobre montar telas, mesmo que ainda o tratemos como se fosse
Quando uma equipe trata o frontend como a etapa de acabamento, o que ela está fazendo, na verdade, é adiar decisões de arquitetura até o momento em que já não sobra margem para tomá-las bem. A API foi desenhada pensando no modelo de dados, não em como vai ser consumida na tela. O contrato entre cliente e servidor foi negociado sem ninguém que entendesse o que acontece quando o usuário perde a conexão no meio de uma ação. E quando o frontend "é montado rápido no final", ele já herdou todos os problemas que ninguém quis resolver antes.
Isso não é uma reclamação de categoria. É uma observação técnica: a maioria dos bugs de produto que viram ticket de suporte não vem de uma lógica de negócio quebrada, vem de um frontend que teve que improvisar em cima de uma base que não pensou nele.
A arquitetura de estado é o trabalho de verdade, não o ajuste de margens
Se você tivesse que explicar para alguém de outra área o que um engenheiro sênior de frontend faz no dia a dia, a resposta honesta não tem nada a ver com CSS. Tem a ver com decidir o que é fonte de verdade e o que é uma cópia derivada. O que vive no servidor, o que vive no cliente, o que é cacheado, quando esse cache é invalidado e o que acontece quando duas abas do mesmo usuário ficam dessincronizadas.
React Query, Zustand, Redux, signals, seja lá o que seu stack usar, são ferramentas para resolver esse problema, não o problema em si. Usar Redux para absolutamente tudo é tão errado quanto não ter estratégia nenhuma de estado e deixar que cada componente resolva sua própria verdade na marra. A pergunta que separa um desenvolvimento frontend bem pensado de um que desaba em produção não é qual biblioteca você escolheu. É se você entendeu, antes de escrever a primeira linha, o que precisa estar sincronizado em tempo real, o que pode viver desatualizado por alguns segundos e o que simplesmente não deveria estar no cliente.
Isso fica mais evidente em equipes que crescem rápido. O estado que era administrável com quatro telas vira uma teia de aranha com quarenta, e é aí que se separa um frontend que escalou de um que passa a precisar de reescritas a cada seis meses.
SSR, CSR ou streaming: a pergunta não é qual é melhor, é o que você está disposto a sacrificar
Server-side rendering, client-side rendering, streaming com React Server Components. Toda palestra técnica apresenta isso como se existisse uma resposta certa esperando para ser descoberta. Não existe. Existem trade-offs, e escolher sem entendê-los é onde começam os problemas de escalabilidade que depois ninguém sabe explicar.
SSR te dá uma primeira renderização rápida e melhor indexação, mas transfere custo de computação para o seu servidor e complica o cacheamento quando o conteúdo é personalizado. CSR simplifica a infraestrutura e funciona bem para aplicações muito interativas, mas penaliza o tempo até o conteúdo ficar visível, principalmente em conexões lentas. O streaming promete o melhor dos dois mundos (conteúdo progressivo, hidratação seletiva), mas soma uma camada de complexidade que uma equipe sem experiência prévia subestima sistematicamente.
A decisão certa depende de quão personalizado é o seu conteúdo, quão crítico é o SEO para aquele produto específico, e quanta capacidade de engenharia a equipe tem para manter a solução escolhida. Uma equipe que copia a arquitetura de rendering de uma empresa com cem engenheiros de plataforma dedicados, sem ter essa capacidade, não está tomando uma decisão técnica. Está tomando uma decisão de marketing interno.
A performance real se mede no celular intermediário de um usuário, não no seu notebook
Um Lighthouse verde não significa nada se o seu usuário real, com uma conexão 4G instável e um celular de dois anos, vê uma tela em branco por oito segundos. A diferença entre performance de laboratório e performance real é exatamente a diferença entre medir em condições ideais e medir o que realmente acontece com quem usa o seu produto.
Core Web Vitals importa porque o Google usa isso para ranquear, sim, mas importa mais porque são proxies razoavelmente bons de frustração real: quanto tempo demora para algo aparecer, o quanto a tela se move enquanto carrega, quanto tempo demora para responder a uma interação. As equipes que só olham métricas sintéticas, geradas em um ambiente controlado, acabam otimizando para um usuário que não existe.
Medir com dados reais de usuários, e não só com execuções automatizadas, muda as prioridades. Às vezes o gargalo não é o bundle de JavaScript, é uma imagem sem otimizar no hero da home. Às vezes não é o rendering, é uma API de terceiros que bloqueia a thread principal por segundos. Sem essa visibilidade, uma equipe de frontend otimiza o que consegue medir fácil, não o que realmente importa.
Cada decisão de frontend é uma decisão de produto, mesmo que ninguém diga isso na reunião
Colocar um skeleton screen em vez de um spinner não é um detalhe visual, é uma aposta sobre como um usuário ansioso percebe o tempo. Decidir se uma ação aparece como bem-sucedida antes que o servidor confirme (atualização otimista) ou se espera a resposta real muda diretamente quantas pessoas completam um fluxo de checkout. Um error boundary mal pensado pode transformar uma falha menor em uma tela em branco que faz alguém abandonar o app para sempre.
Essas não são decisões estéticas. São decisões de produto com impacto direto em conversão, em retenção, em quantas pessoas ficam frustradas o suficiente para não voltar. O problema é que quase nunca são discutidas nesses termos. São tratadas como implementação, algo que o frontend "resolve" depois que o produto já definiu o que importa. Quando, na verdade, cada uma dessas decisões está definindo a experiência tanto quanto qualquer feature nova no roadmap.
Tratar o desenvolvimento frontend como a etapa depois do backend é a razão pela qual a UI não escala
Aqui está o padrão que se repete empresa após empresa: o frontend cresce aos trancos porque nunca teve uma arquitetura pensada com antecedência, só foi absorvendo features até que cada mudança nova quebra três coisas antigas. Ninguém planejou a arquitetura de estado. Ninguém decidiu com critério a estratégia de rendering. Ninguém mediu performance com dados reais até as reclamações começarem a chegar. Tudo isso foi ficando para depois porque, na cabeça da equipe, o frontend era a parte que se resolve rápido no final.
E quando finalmente explode, a solução proposta é quase sempre uma reescrita completa. Não porque o frontend fosse impossível de consertar, mas porque nunca foi tratado como um sistema com arquitetura própria, com decisões que mereciam o mesmo nível de discussão que qualquer definição de backend. Acumulou-se dívida técnica em um lugar onde ninguém estava olhando com seriedade suficiente.
A hierarquia é que está errada, não a tecnologia
O problema de fundo não é técnico. É que continuamos organizando equipes e conversas como se o frontend fosse uma etapa posterior, quando na verdade é onde se decide se um produto parece rápido, confiável e coerente, ou se parece quebrado mesmo que o backend responda perfeitamente. Um engenheiro sênior de frontend não é alguém que domina os seletores de CSS melhor que ninguém. É alguém que entende que cada linha de código no cliente é uma aposta sobre como se comporta um sistema distribuído completo, com todas as suas falhas de rede, seus estados intermediários e seus usuários reais usando hardware real. Enquanto as empresas continuarem atribuindo esse nível de responsabilidade a quem "cuida para que fique bonito", vão continuar pagando em produção o custo de uma hierarquia que nunca fez sentido.
