Onde Java com Spring Boot ainda ganha de Node.js (e onde não)

Toda thread de "Java vs Node" vira a mesma briga de torcida: um lado fala em verbosidade e AbstractFactoryBean, o outro fala em callback hell e node_modules com peso de buraco negro. É entretenimento, não engenharia.

A pergunta que interessa é outra: onde a maturidade de Java + Spring Boot resolve um problema que Node + TypeScript ainda resolvem peça por peça? E o inverso: onde essa mesma maturidade vira peso morto e o Node ganha limpo?

Vou tentar responder isso sem torcida, do jeito que eu escolheria stack num projeto de verdade.

Maturidade não é idade. É densidade de respostas para o tédio.

"Java é mais maduro porque é mais velho" é argumento preguiçoso. COBOL é mais velho ainda. Maturidade de ecossistema não se mede em anos. Mede-se em quantos problemas chatos de produção já têm uma resposta canônica, testada por milhares de empresas, dentro da caixa.

Os problemas chatos são sempre os mesmos: transação distribuída, retry com backoff, pool de conexão, paginação, autorização por método, processamento em lote de milhões de linhas, observabilidade, migração de schema, connection draining num deploy. Nada disso é glamouroso. Tudo isso quebra produção às 3 da manhã.

O eixo certo de comparação é simples: quando você bate nesse problema, o ecossistema te entrega uma resposta pronta e battle-tested, ou te entrega três libs de um mantenedor só e um post de blog de 2019?

Onde Java + Spring Boot é a escolha mais válida

1. Domínio transacional pesado (banco, seguro, ERP, logística). Spring nasceu no mundo enterprise e isso, aqui, é uma vantagem e não um estigma. Transação declarativa com @Transactional, propagação de transação entre camadas, integração com JTA pra transação distribuída de verdade, Spring Data pra repositório sem boilerplate, Spring Batch pra processar lote de milhões de registros com checkpoint e restart. No Node você monta isso com Prisma, mais uma lib de fila, mais uma lib de retry, mais cola escrita à mão. E cada peça é de um mantenedor diferente.

2. Times grandes em monolitos de vida longa. Tipagem forte de verdade, garantida pela JVM em runtime, mais refatoração de IDE que move 400 arquivos sem medo, mais um compilador que reclama antes do deploy. Num código que vai viver 8 anos e passar por 30 desenvolvedores, esse rigor é um recurso, não burocracia. TypeScript te dá muito disso na hora de escrever, mas, como veremos, some no runtime.

3. CPU-bound e paralelismo real. Processamento pesado, cálculo, transformação de dados, algoritmo que satura núcleo: a JVM tem multithreading de verdade, com memória compartilhada e um GC que teve 25 anos de tuning. O modelo single-thread + event loop do Node foi desenhado pra I/O, não pra queimar CPU. Workload pesado de CPU bloqueia o loop e você acaba fazendo malabarismo com worker_threads ou cluster de processos.

4. Operação e diagnóstico em produção. Aqui a diferença é gritante. Java Flight Recorder, heap dump, thread dump, profiling de produção com overhead quase zero, GC observável, JMX. Quando um serviço Java vaza memória, você tira um heap dump e vê o objeto culpado. Quando um serviço Node vaza memória, você reza, dá --inspect e compara snapshots de heap torcendo pra reproduzir. Décadas de ferramenta de produção não se replicam num ciclo de hype.

5. Ecossistema enterprise coeso e de mantenedor sério. Spring Security pra authz/authn que cobre OAuth2, SAML, method security; Spring Cloud pra service discovery, config central, circuit breaker; drivers JDBC maduros pra todo banco que existe; Micrometer pra métrica. É um ecossistema curado e versionado junto, mantido por uma fundação (hoje VMware/Broadcom) com release train previsível. Não é um mosaico de pacotes npm com graus de abandono variados.

6. Estabilidade de contrato no longo prazo. A JVM leva compatibilidade retroativa quase a religião. Código de 2010 ainda roda. No ecossistema Node, um major de framework a cada 18 meses e a roda da fortuna de node_modules cobram um imposto de manutenção que, num produto de vida longa, não é trivial.

Onde Node + TypeScript continuam ganhando limpo

Seria desonesto parar aqui. É tão desonesto quanto fingir que Node não tem o seu próprio território, onde Java é que vira o peso errado.

1. I/O-bound com milhares de conexões leves. BFF, API gateway, proxy, realtime (WebSocket, SSE), serviço que passa o dia esperando rede e banco. O event loop foi feito exatamente pra isso e entrega throughput altíssimo com footprint de memória baixo. Aqui o modelo do Node é uma vantagem de arquitetura, não uma limitação.

2. Full-stack numa linguagem só. Front e back em TypeScript, tipos compartilhados de ponta a ponta, um time só, um build mental só. Pra produto web, especialmente com Next.js, tRPC, server actions, isso é uma alavanca de velocidade que o split Java-no-back/TS-no-front não tem.

3. Serverless, edge e cold start. Função efêmera, edge runtime, escala a zero. O cold start da JVM historicamente foi cruel aqui (GraalVM native image ajuda, mas com seu próprio custo de build e pegadinhas). Node sobe em milissegundos e é o default natural do mundo serverless.

4. Velocidade de iteração e prototipagem. Startup validando hipótese, MVP, produto que muda de forma toda semana: o ciclo de Node é mais curto, o ecossistema de frontend é nativo, e a cerimônia é menor. A maturidade do Spring é um ativo quando o domínio é estável, e um peso quando você ainda nem sabe qual é o domínio.

A nuance que muda a conta: Virtual Threads

Quem usa "Node escala melhor I/O porque é assíncrono" como trunfo precisa atualizar o benchmark mental. Java 21 trouxe Virtual Threads (Project Loom): threads leves gerenciadas pela JVM, baratas aos milhões, que entregam concorrência de I/O massiva sem o programador escrever código assíncrono. Você escreve código bloqueante, linear, fácil de ler, e a JVM faz o malabarismo por baixo.

Na prática, isso erode boa parte da vantagem histórica do Node em I/O-bound de alta concorrência, mantendo o estilo de programação simples. Não apaga as outras vantagens do Node (cold start, full-stack, iteração), mas tira da mesa o argumento mais repetido contra a JVM. Vale levar isso em conta antes de decidir por reflexo.

O detalhe que quase ninguém pondera: o tipo some no runtime

TypeScript é excelente, e eu uso muito. Mas é honesto encarar uma diferença estrutural: o tipo do TS existe só em tempo de compilação. Depois do build, ele é apagado (type erasure) e o que roda é JavaScript puro, sem nenhuma garantia. Aquele payload da borda do sistema que você tipou lindamente como User? Em runtime, é any com fé.

Por isso o mundo TS sério vive de Zod, io-ts, class-validator: você reconstrói no runtime a validação que o tipo prometeu mas não cumpre. Na JVM, o tipo é verificado e mantido em runtime pela própria plataforma. Não é "Java é melhor". É entender que a garantia do TS é mais fina do que parece, e que em domínio crítico isso pesa.

O que realmente decide: o requisito, não a preferência

Repare que nenhuma escolha aqui veio de "qual linguagem é melhor". Veio do formato do problema.

Sem requisito, não tem arquitetura, nem escolha de stack.

"Spring ou Node?" responde a "meu domínio é transacional pesado e de vida longa, ou é I/O-bound que muda toda semana?"
"Tipo em runtime importa?" responde a "o custo de um dado malformado passar é um warning ou é dinheiro indo embora?"
"JVM ou event loop?" responde a "eu queimo CPU ou eu espero rede?"

Quem escolhe stack pela linguagem que domina, pela que está no hype, ou pela que rendeu a melhor thread no X, está chutando. E chute de stack você carrega por anos.

A leitura madura é chata de tão simples: Java + Spring Boot quando o domínio é pesado, transacional, de vida longa, com time grande e operação crítica. Node + TypeScript quando é I/O-bound, full-stack, serverless, ou um produto que ainda está descobrindo o que é. A maioria dos projetos cai limpo de um lado ou do outro assim que você descreve o requisito em voz alta.

A regra prática

Não escolha pela linguagem que você ama. Escolha pela maturidade que o seu requisito exige, e aceite o custo do que você está deixando na mesa.

Se o seu problema é processar lote bancário com transação distribuída e auditoria de 7 anos, a verbosidade do Spring é o preço de uma resposta pronta e testada. Se o seu problema é subir um BFF que escala a zero e compartilha tipo com o front, a cerimônia da JVM é peso morto.

Os dois são ótimos. Nenhum é universal. E a pessoa que te disser que um deles vence sempre está vendendo a stack que ela domina, não resolvendo o seu problema.

TL;DR: Java + Spring Boot ganha por maturidade onde dói: domínio transacional pesado, time grande em código de vida longa, CPU-bound, diagnóstico de produção e ecossistema enterprise coeso. E Virtual Threads (Java 21) ainda derrubou o velho argumento de que Node escala I/O melhor. Node + TypeScript ganha em I/O-bound de alta concorrência, full-stack numa língua só, serverless/edge e velocidade de iteração, lembrando que o tipo do TS some no runtime. Decida pelo requisito, nunca pela torcida.