Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
A referência publicada no Stack Overflow por Laurie Crean traz um recorte que vale discutir sem repetir o texto original: O assunto coloca React no centro da conversa e ajuda a separar novidade de impacto real para quem mantém software em produção.
Também vale observar o lado humano da decisão. Ferramenta nova, biblioteca nova ou padrão novo quase sempre mexe em fluxo de revisão, onboarding, ownership e qualidade da comunicação entre áreas. Se a proposta depende de conhecimento concentrado demais, a execução até pode parecer rápida no início, mas o custo aparece quando a manutenção precisa escalar.
Entendo a empolgação com frontend/build, mas eu olharia primeiro para documentação. Se isso não fica claro, a novidade só troca um gargalo por outro.
Boa discussão para trazer exemplos reais. O que funcionou em um produto pequeno pode não sobreviver em uma base grande e cheia de dependências.
Quem fica responsável por DevOps quando o primeiro dev que puxou isso sair do projeto?
Tem valor, só não compraria como regra geral. Precisa ficar claro quem opera, quem revisa e o que acontece quando falha.
O que seria sinal de parar esse teste antes de virar padrão?
frontend/build sem documentação vira dor depois
Quem cuida de documentação quando esse frontend/build sair da fase de empolgação?