TypeScript: ainda vale a pena ou virou cargo cult? · obrenoalvim

Vou dar a opinião impopular: TypeScript vale a pena, mas não pelo motivo que a maioria defende.

O argumento padrão que não me convence

"TypeScript previne bugs em produção." Previne alguns. Mas os bugs mais graves que já vi em produção não eram de tipo — eram de lógica de negócio, condições de corrida, edge cases que nenhum sistema de tipos captura.

Se você está vendendo TypeScript como "menos bugs em produção", está prometendo mais do que entrega.

O que realmente convence

Documentação viva. Um método bem tipado é auto-documentado. Você abre uma função e sabe exatamente o que entra e o que sai, sem ler comentários desatualizados.

Refatoração com confiança. Quando você muda uma interface e 40 arquivos quebram, você sabe exatamente onde trabalhar. Em JavaScript puro, descobre em runtime.

DX em times. Para um projeto solo, TypeScript pode ser overhead. Para times de 5+, a comunicação via tipos compensa o setup.

A ressalva que poucos falam

TypeScript mal usado é pior do que JavaScript. any em todo lugar, type assertions sem verificação, tipos gerados automaticamente que ninguém lê — isso não é TypeScript, é JavaScript com cerimônia.

Se vai usar TypeScript, use de verdade. Se não, use JavaScript com JSDoc. O meio-termo é o pior dos dois mundos.

Vocês usam TypeScript no projeto inteiro ou tem partes que voltaram para JS por praticidade?

Vou dar a opinião impopular: TypeScript vale a pena, mas não pelo motivo que a maioria defende.

Não acho que é uma opinião impopular, dependendo da comunidade.

São poucos os que realmente utilizam TypeScript corretamenta. Não vou dizer que eu sou um desses casos, pois só utilizo para code throw away. Literalmente apenas para testes. Tudo que eu faço é praticamente em Rust ou C. No entanto eu consigo observar bem quando estão usando TypeScript de maneira inteligente por ter tido uma experiência de 3 anos codificando em TypeScript todos os dias. A maioria faz gambiara pois JavaScript permite isso. TypeScript apenas reduz isso, mas com o any, é JavaScript com extensão diferente.

eram de lógica de negócio, condições de corrida, edge cases que nenhum sistema de tipos captura.

Ponto EXTREMAMENTE IMPORTANTE. A maioria dos bugs são de lógica. Especialmente relacionados a memória. Outro ponto é questões de otimização.

TypeScript mal usado é pior do que JavaScript. any em todo lugar, type assertions sem verificação, tipos gerados automaticamente que ninguém lê — isso não é TypeScript, é JavaScript com cerimônia.

Vocẽ não poderia ter mais razão. Corretíssimo.

Toda ferramenta tem seu espaço. Para ser sincero, eu nunca curti programar em JavaScript/TypeScript por diversos problemas inerente a linguagem, mas é muito fácil de aprender e utilizar. O problema é que por ser fácil, ou seja, menos restrito, abre espaço para bugs técnicos e de lógica. O mesmo se aplica para Python, mas Python ainda consegue capturar mais problemas lógicos que TypeScript.

Quando você muda uma interface e 40 arquivos quebram, você sabe exatamente onde trabalhar. Em JavaScript puro, descobre em runtime.

Aqui eu diria que é um problema de engenharia/design. Uma interface é um contrato. Se o contrato muda, tudo muda e como você mencionou, muitos arquivos quebram. Todo dev deveria parar um pouco e aprender sobre engenharia de software/design systems. Há quem criei e passe a utilizar interfaces de maneira indiscriminada como se fosse uma estrutura qualquer.