Executando verificação de segurança...
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.

Carregando publicação patrocinada...
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?