DROPS: Verdades duras sobre Typescript

E que defensores não comentam

DISCLAIMER: Estou escrevendo esse post meio stressado com um assunto que vi no meu e-mail sobre um comentário no dev.to e antes que a resposta seja rasa igual a que tive no dev.to, deixar avisado aqui que já trabalhei com Typescript em aplicações que estão em produção por pelo menos 1 ano.

Vamos lá Typescript pode ter sim suas vantagens e já fiz meus pedidos de desculpas do porque para mim não faz sentido, mas agora vou um pouco além sobre algumas coisas que não vejo ninguém discutir.

Falta de tipos é um problema?

JS é uma linguagem ruim por ser fracamente tipada é um argumento comum e não é de hoje que escuto, já tem mais de 12 anos que ouço isso. Quando dizem isso ignoram anos de softwares entregues produção e funcionais escritos em PHP e JS.

Uma linguagem fracamente tipada tem diferenças no seu uso e muitos defensores de Typescript e outros supersets de JS, quase sempre tem mais experiencia com outras linguagens e ao invés de procurar entender como JS faz cast de valor e culpa a ferramenta ao invés de questionar seus próprio entendimento.

A conversão perigosa muitas vezes está escondida e o seu uso traz sim mais bugs e problemas de performance, mas a falta de conhecimento em JS que faz isso e a pessoa pode cometer os mesmo erros em Typescript e não será os tipos ou o superset que evitará.

JS não tem mais bugs por falta de tipos

Na realidade isso é muito subjetivo e se esse é motivo de uma aplicação ter mais ou menos bugs os sites feitos em flash/flex ou em jscript no passado com certeza teriam se mantido como padrão, afinal eles seguiam a spec do Ecmascript 4 que continha imports e tipos.

A forma que se escreve JS mudou e melhorou muito, a aproximação com uma abordagem mais funcional tem ajudado muito nisso, responsabilidade única e funções puras, deixam os programas menos acoplados, fora avanços em arquitetura e um bom processo de Code Review e TDD já conseguem atuar melhor na redução de bugs do que um superset de linguagem.

Outro fator usando esse lógica do subtitulo, para se levar em consideração é que aplicações escritas em linguagens fortemente tipadas nunca ou quase nunca teriam bugs e possivelmente Assembly nem funcionaria por não ser nem mesmo tipada.

Não é bem assim o "Consigo pegar os bugs antes"

Uma boa forma também de fazer isso é escrever testes para a aplicação e ter processos rigidos para controle próprio ao invés de delegar isso para uma ferramenta.

A adição do tempo de compilação que te diz que um número está recebendo uma string é realmente te evita um bug? Mas quanto ao tempo perdido por falta de uma definição de tipo de uma biblioteca externa ou uma propriedade vinda do objeto window ou global?

Você ver uma variavel que é uma string e recebe o resultado de uma função é realmente tão mágico assim ou é o seu viés de familiaridade com linguagens tipadas que não te deixa escrever JS direito e por isso você reclama?

Aumento da complexidade

Para alguém que está iniciando seu aprendizado Typescript se torna um grande ruído, primeiro porque ela vai ter configurar um ambiente, depois vai ter que fazer uma compilação do código e depois ver o resultado, traz um aumento grande de complexidade.

JS é uma linguagem projetada para ser simples e que designers sem conhecimentos de computação poderiam trabalhar com ela. Claro que 20 anos depois o número de aplicações escritas em JS aumentou tanto em complexidade quanto em número.

Esse aumento cria a necessidade de novas ferramentas para aumentar a confiança, mas o problema que o Typescript pretende resolver, pode ser resolvido com mais educação do que mais amarras no processo de desenvolvimento.

Isso que para um iniciante em desenvolvimento talvez perca o interesse por essa imposição de uma ferramenta que pouco importa para ele atingir o resultado de um entregar uma aplicação.

E para o dia a dia de trabalho essa etapa cria mais obstaculos por conta de erros que muitas vezes você vai ser ver contornando e que vou falar mais a frente.

Você vai usar o any no seu primeiro problema real

Está precisando configurar uma entrada e está tomando muito tempo de compilação? Bem provavel que vai usar any como tipo e logo se torna uma padrão da aplicação.

Afinal se usando any seu código está funcionando e com tipo não está a tendencia humana é ir para o mais fácil. Ainda mais em projetos com tempo apertado e ritmo pegado em que erros em tempo de compilação mais atrapalham que ajudam.

Aqui você só ficou com maleficios do typescript e zero beneficios.

O node_modules tem ficado maior por culpa dele

Muitos desenvolvedores sombe seus projetos escritos em Typescript no npm e com isso o tamanho dos pacotes que antes eram de alguns kb se tornaram mb e agora temos node_modules ocupando Gigas em alguns projetos.

Mas temos definições de typos e o Intellisense do VSCode está funcionando bonitinho. #ironia

Basicamente são alguns pontos para se considerar antes de usar Typescript, é importante lembrar que é só uma ferramenta e não uma religião.

O que serviu para você e te salvou, lembre que já me salvou, já me prejudicou e também já me atrapalhou muito. Não é de hoje que falo de Typescript e procuro sempre acompanhar o que está rolando. Ainda mais agora com o Deno que tem Typescript embutido.

Fica de olho no que está rolando com typescript, aprenda ele, mas priorize o conhecimento de base e não de ferramentas modinhas.