O Custo Escondido que Ninguém te Conta

Vamos falar sobre algo que tira o sono de qualquer desenvolvedor que tenta colocar uma aplicação web séria no ar: o custo escondido de fazer tudo funcionar junto.

Você conhece essa sensação. Escolheu seu framework, seu ORM, sua biblioteca de validação, seu frontend, seu bundler. Tudo parece perfeito no papel. Aí começa a construir funcionalidades de verdade e descobre que sua biblioteca de validação não entende direito o formato que seu ORM retorna. O server-side rendering do seu framework frontend não se dá bem com o middleware do seu servidor. O gerenciamento de sessões faz suposições que explodem quando você tenta fazer deploy para a edge.

Cada ferramenta individualmente é excelente. As juntas entre elas são um pesadelo.

Como Chegamos Aqui

O ecossistema JavaScript sempre valorizou composabilidade em vez de coesão. Isso não é necessariamente errado — a filosofia UNIX nos serviu bem por décadas. O problema é que aplicações web não são pipelines de transformações isoladas de dados. São emaranhados de suposições compartilhadas: formatos de request, limites de validação, fluxos de autenticação, contextos de renderização, alvos de deploy.

Quando o Django surgiu em 2005, fez uma aposta: desenvolvedores trocariam alguma flexibilidade por um sistema coerente. Você ainda podia sair do caminho quando precisava, mas dentro dele, tudo era projetado para funcionar junto. Essa responsabilidade significava menos surpresas.

Os frameworks PHP entenderam isso também. Laravel, Symfony, Yii — todos forneciam aquela sensação de "um sistema coerente". Você sabia o que era território oficial e o que exigia aventurar-se na selva.

Depois o JavaScript comeu o servidor, e em grande parte perdemos isso.

A Armadilha dos Meta-Frameworks

Os meta-frameworks modernos melhoraram as coisas em alguns aspectos. Next.js, Nuxt, SvelteKit — trouxeram de volta uma stack coerente. Mas fizeram isso estreitando suas escolhas em vez de expandi-las.

O que quero dizer é o seguinte: Next.js é uma excelente stack para React. Mas se você se apaixonar pela performance do Solid ou pela simplicidade do Svelte, não é só trocar a camada de visualização. Você adota um meta-framework diferente, com convenções diferentes, padrões de roteamento diferentes, suposições de backend diferentes. Aprende os mesmos problemas que já resolveu, só que com sintaxe diferente.

Isso cria uma situação estranha. O ecossistema frontend continua inovando, mas trocar de abordagem quase exige começar do zero. Desenvolvedores React e desenvolvedores Svelte resolvem os mesmos problemas de backend independentemente, de formas levemente diferentes, para sempre.

A Loteria dos Runtimes

E depois tem a fragmentação de runtimes. Node.js, Deno, Bun — todos são plataformas capazes, mas a maioria dos frameworks é efetivamente específica para um runtime. Quando um framework diz que tem suporte ao Deno, geralmente significa apenas que "o Deno consegue rodar nosso código Node." Não é a mesma coisa que o framework ser projetado em torno das APIs nativas e do modelo de execução do Deno.

Isso importa mais do que parece. O runtime que você escolhe afeta características de performance, alvos de deploy e modelos de segurança. Se prender a um framework que só funciona de verdade em um runtime limita suas opções conforme o ecossistema evolui.

O que Realmente Precisamos

Aí está: aplicações web têm camadas naturais que não precisam estar acopladas.

Frontends descrevem UI do navegador. Backends tratam requests, dados e lógica da aplicação. Runtimes são alvos de execução. Esses concerns deveriam poder variar independentemente.

Imagine construir uma rota com React porque você precisa do seu ecossistema de componentes. Construir outra com Svelte porque performance importa mais ali. Rodar suas rotas Node.js hoje, mas fazer deploy das suas rotas TypeScript no Bun quando precisar da velocidade. Tudo na mesma aplicação, com o mesmo modelo de backend, a mesma validação, as mesmas sessões.

Isso não é pensamento mágico. É tratar concerns como concerns separados, que é como bom software sempre foi construído.

O Framework Deveria Cuidar das Juntas

Não estou argumentando para um framework dominar todos. Estou argumentando que um framework deveria assumir a responsabilidade de fazer suas peças funcionarem juntas. Você ainda deveria poder sair da stack oficial quando precisar — ninguém shipa defaults perfeitos para todo caso de uso. Mas quando você fica dentro do framework, as juntas deveriam ser problema do framework para resolver, não seu.

Um framework que te faz pensar em roteamento, validação, acesso a dados e renderização como problemas separados que você tem que colar juntos não é um framework. É uma sugestão.

Os melhores frameworks te dão propriedade da sua lógica de negócio enquanto assumem propriedade de todo o resto.

Na NameOcean, vimos como a complexidade de hospedagem pode se multiplicar quando sua stack é fragmentada. Escolher um framework que respeita separação de concerns — que te permite trocar peças sem reescrever tudo — torna deploy, escalabilidade e manutenção dramaticamente mais simples.

A questão não é se você deve usar um framework. É se seu framework está trabalhando para você ou apenas adicionando mais uma camada de decisões que você não precisava fazer.

O que significaria construir sua próxima aplicação com uma ferramenta que cuida das juntas? Isso vale a pena pensar antes de você scaffoldear seu próximo projeto.