1
obrenoalvim
1 min de leitura ·

TypeScript: ainda vale a pena ou virou cargo cult?

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?

Carregando publicação patrocinada...
2

Quando uma linguagem tem tipos é ótimo pra evitar pegadinhas que as vezes vão além do seu código, imagina você esta consumindo uma api de terceiros e ele simplesmente muda o tipo do lado dele de float para string e você usa esse valor pra uma operação matemática, isso pode causar confusão e bugs inesperados, tipos são muito do que verbosidade ou coisa do tipo, é uma pretensão de contrato definido para um processo. Se você escolhe javascript ou qualquer linguagem com tipagem dinamica ou fracamente tipada, você basicamente está assumindo uma responsabilidade sobre a mutação dos dados e é isso.

1

O exemplo da API de terceiro mudando float para string é um dos mais concretos que existem para justificar tipagem. Você não está protegendo seu código, está protegendo a fronteira entre seu código e um sistema que você não controla. Esse argumento convence muito mais do que o genérico de 'menos bugs'. O ponto que defendo é que esse caso específico, validação de fronteira, resolve melhor com parsing explícito (zod, por exemplo) do que com tipos estáticos sozinhos, porque o TypeScript não valida em runtime. Os dois juntos fazem sentido. Você usa alguma lib de validação de schema junto com TS, ou confia só nos tipos?

Conteúdo excluído
1

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.

1

Faz sentido, quem vem de Rust ou C olha para TypeScript de outro ângulo. Sobre Python capturar mais problemas lógicos: discordo um pouco. Python é dinâmico e a maioria dos erros de lógica só aparecem em runtime também, não tem como escapar. A diferença do TypeScript é a modelagem explícita de domínio, que força você a pensar nos contratos antes de escrever. Sobre interfaces quebrando 40 arquivos: concordo que é design, mas prefiro o compilador me mostrando o impacto do que descobrir isso em code review ou em produção. Você usa Rust no trabalho ou só em projetos pessoais?

1

No momento só em projetos pessoas, pois mercado Brasileiro para Rust é bem pequeno (se é que existe). Porém estou estudando bastante inglês para abrir horizontes no mercado internacional.

1

Mercado de Rust no Brasil é quase inexistente, você está certo. As vagas existem, mas estão todas nos EUA, UK e Alemanha, principalmente em infra, sistemas embarcados e fintech. O inglês abre esse mercado de forma bem direta. Estudar Rust e inglês ao mesmo tempo é uma combinação que faz sentido: quando o inglês chegar em nível de entrevista, o Rust já vai estar num ponto que diferencia. Qual é o seu nível de inglês hoje, está mais no reading técnico ou já consegue se comunicar bem também?

3

Eu consigo ler praticamente tudo em inglês sem consultar o dicionário. Porém como não tenho um ambiente favorável a escuta e fala, acabo tendo uma deficiência nisso. Ainda estou formulando caminhos para lidar com isso de maneira controlada.

Sobre escrita, é possível, eu apenas tenho evitado um pouco por preguiça. Como não tenho muitos amigos, e nenhum que sabe inglês, não consigo criar um contato frequente que treine essa skill. Porém eu comecei a me comprometer mais e escrita não será mais um problema em alguns meses

1

Thank you, gpt.
Eu pensava que typescript era besteira até começar a usar o flutter por uns 2 meses e depois voltar pra fazer uns ajustes na API que ele consumia.
É igual tomar café premium, nunca mais você conseguirá voltar ao "barato". Nunca mais será a mesma coisa.
Outra coisa: overhead é quando você dá muitas voltas onde poderia fazer algo simples. O detalhe é que typescript não é complexo. Você literalmente usa 1 comando pra começar a usar, tudo fica mais fácil e a exportação é JS puro. Sinceramente, essa discussão é muito 2010.

Outro ponto furado do seu argumento: a maioria dos erros ser de lógica não invalida o uso da outra ferramenta. Você não é um MS-DOS e consegue fazer mais de uma coisa ao mesmo tempo.

3

Eu sou o oposto. TypeScript para mim é o café barato. O foco da ferramenta é claramente fazer funcionar. Projetos reais tem outras preocupações além de fazer somente funcionar. TypeScript abre muitas portas para gambiarras que acaba gerando mais bugs lógicos.

Compare com outras linguagens mais rígidas. Os problemas ainda existem, mas em menor quantidade por ser mais restrita.

Um ponto importante é que o ataque não foi a ferramenta, e sim a um argumento relacionado a ferramenta.

1

Concordo que a flexibilidade do TypeScript tem um custo, o any e os type assertions são a porta de entrada pra maioria das gambiarras. Mas acho que o problema não é a ferramenta, é o custo de adoção de linguagens mais rígidas. Rust ou Go eliminam boa parte disso, mas a barreira de entrada e o ecossistema web ainda são limitantes pra maioria dos times. O ponto sobre atacar o argumento e não a ferramenta é válido, o argumento padrão de 'TS previne bugs em prod' realmente é fraco. Você usa alguma linguagem mais rígida no dia a dia em produção?

1

A comparação com Flutter é boa, esse ponto de não conseguir voltar é real. O que coloquei não é contra TypeScript, é contra o argumento específico de venda. Porque quem resiste ao TS geralmente não vai mudar de ideia com "previne bugs em produção", e aí você fica numa discussão que não leva a lugar nenhum. Sobre o overhead: concordo que começar é simples, mas o custo aparece em projetos legados com libs sem types, configuração de build e integração de ferramentas. Não é overhead de aprendizado, é de manutenção. A crítica sobre fazer mais de uma coisa ao mesmo tempo é justa, mas não era o foco do argumento. Você já pegou um projeto legado grande para migrar para TS, ou sempre começou do zero?