TypeScript: Devo ou não usar?

See other articles

Criado em 2012 pela Microsoft e possuindo como arquiteto o renomado engenheiro de software Anders Hejlsberg (também responsável pelas linguagens C# e pela plataforma .NET), o TypeScript pode ser descrito atualmente como um superset (ou superconjunto) da linguagem JavaScript. Mas o que isso significa?

TypeScript é um superset de JavaScript
Ilustração mostrando como o TypeScript engloba e adiciona funcionalidades ao JavaScript.

Ao usar a linguagem JavaScript como base, o TypeScript adiciona novas camadas de funcionalidades que, na visão da Microsoft e de inúmeros desenvolvedores, faltava no JavaScript. Propor a implementação dessas novas funcionalidades diretamente ao JavaScript (ou ao órgão responsável pela sua padronização, ECMA) demandaria muito esforço, levaria anos entre discussões com a comunidade e definição das especificações, e o resultado poderia sair muito diferente do esperado pela Microsoft.

A solução encontrada foi criar uma nova linguagem que entende e aceita toda a sintaxe JavaScript existente, mas também a estende com novas funcionalidades. Um programa JavaScript é completamente aceito pelo compilador do TypeScript. E é por conta dessa “retrocompatibilidade” que o mesmo é chamado de superset (ao contrário do Elm ou Dart, que não possuem compatibilidade direta com JavaScript, mas compilam seus códigos para JS).

// Esse código é válido tanto em JavaScript,
// quanto em TypeScript

function Greetings(name = 'Pessoa') {
  return `Olá ${name}`;
}



// Já o código abaixo é válido apenas em TypeScript

function Greetings(name: string = 'Pessoa'): string {
  return `Olá ${name}`;
}

Dentre as novas funcionalidades que o TypeScript implementa, estão:

Muitas dessas funcionalidades já poderiam ser emuladas com JavaScript puro, mas a sintaxe do TypeScript permite um código muito mais claro e limpo, seguindo padrões de escrita conhecidos em outras linguagens (como Java e C#), além de permitir checagem do código e autocomplete inteligente pelo próprio editor/IDE, uma vez que uma tipagem forte e estática permite que o código seja interpretado de maneira clara antes de ser executado.

O resultado foi tão satisfatório que uma certa parcela da comunidade adotou o TypeScript como linguagem principal, incluindo um dos frameworks front-end mais famosos da atualidade: Angular. E com toda essa popularidade meteórica (com perdão do trocadilho ao Meteor), que surge o inevitável questionamento:

Vale a pena usar TypeScript?

Resposta curta: Depende.

Resposta longa: Também depende, mas do seu caso…

Sistemas legados

Na maioria dos casos, sistemas legados são sinônimo de problema. Código mal estruturado, bibliotecas defasadas, e bugs que passaram despercebidos geralmente são problemas recorrentes. Além disso, é pouco comum que seja dada abertura para refatoração desse código. De forma que uma reimplementação em TypeScript não faz muito sentido, uma vez que seria necessário escrever boa parte do código novamente para usar todas as funcionalidades que fazem essa linguagem tão atrativa.

Projetos pequenos

Se você está trabalhando em um projeto pequeno, seja ele um projeto pessoal ou para um cliente, talvez não faça sentido usar uma linguagem que tem como principal ganho a robustez do seu software no longo prazo. Projetos pequenos têm uma base de código ínfima, e podem não durar muito tempo, nem demandar muito esforço de manutenção. Portanto, a não ser que você queira usar essa oportunidade para aprender coisas novas, ou caso você saiba que o projeto pode vir a escalar no futuro, talvez o TypeScript soe como um canhão para matar uma mosca.

Projetos médios/grandes

É aqui que o TypeScript começa a brilhar. Projetos com uma base de código maior, que tem previsão de crescimento e manutenção de médio a longo prazo, geralmente começam bem estruturados, mas com negligência tendem a virar um certo caos. Isso pode ocorrer por inúmeros motivos: desleixo dos desenvolvedores, arquitetura inapropriada, falta de programadores experientes na equipe, etc. E não é difícil concluir que códigos bagunçados são moradia perfeita para bugs difíceis de resolver. Nesse caso, uma linguagem que que permite tipagem estática forte, além de maneiras claras de entender e levantar erros no código já em tempo de desenvolvimento, faz muita diferença.

Projetos que envolvam muitos devs (ou devs inexperientes)

Complementando o item acima, projetos que possuem grandes equipes (ou com devs iniciantes, em um ambiente sem prática de code review) geralmente tendem a nos levar a códigos fora do padrão. Eu mesmo já presenciei isso em projetos React com os quais trabalhei. Cada programador desenvolvia usando um padrão e, com a corda dos prazos sempre no pescoço e ausência de um arquiteto desde o início, acabávamos com um código onde cada componente tinha um estilo e organização diferente. Um verdadeiro pesadelo para debugar ou dar manutenção posterior. Neste ponto, minha experiência com Angular foi um pouco mais positiva. Por ser um framework criado em volta do TypeScript (e que faz questão de “forçar” a linguagem e seus padrões sempre que possível), fica muito mais difícil que um desenvolvedor cometa algum deslize grave, ou que grandes equipes fujam do padrão de escrita de código. Eu acredito que grande parte desse mérito seja a decisão da equipe do Angular em usar TypeScript.

Projetos que possuam pontos críticos

É sempre importante tratar qualquer projeto com seriedade. Mas sabemos que um sistema de monitoramento de produtos inflamáveis em tempo real é mais crítico do que um site institucional. A API de uma fintech sempre vai ser mais crítica do que um blog pessoal, por exemplo. Nestes casos usar tipagem forte, estática, e uma linguagem que facilite a escrita de um código bem estruturado pode fazer toda diferença entre pegar um bug em tempo de desenvolvimento, ou descobri-lo em produção após uma invasão que custe muito caro financeiramente à empresa. É claro que não é apenas a escolha de uma linguagem que irá mitigar esse tipo de sinistro. Testes automatizados, uma boa arquitetura, bons profissionais, e um bom planejamento são alguns itens que podem diminuir muito os riscos de problemas maiores em sistemas críticos. Porém um ponto muito importante nesse tipo de projetos definitivamente também é a linguagem escolhida na hora do desenvolvimento. A meu ver, esse seria mais um caso onde o TypeScript ganha destaque.

Ok. Entendi. O TypeScript deve ser usado em sistemas críticos e projetos grandes, correto?

Não necessariamente. Eric Elliot, em um artigo muito interessante que contrapõe o uso indiscriminado do TypeScript em detrimento de JavaScript puro deixa claro, dentre outras coisas:

Se você aplica TDD e code reviews, pouquíssimos erros de tipagem irão escapar para o seu código de produção.

Esse argumento também extrapola para outros itens aqui levantados: Um código bem escrito e organizado não é mérito de uma linguagem. É possível atingir níveis admiráveis de qualidade de código em quase qualquer linguagem ou framework. O TypeScript vem como uma forma elegante de facilitar essa padronização, e também como um atrativo para desenvolvedores que migraram de linguagens com um formato parecido (geralmente usadas no back-end), o que inclusive facilita a adesão de programadores back-end mais pragmáticos e resistentes, que ainda não abrem mão de uma linguagem mais robusta em detrimento do JavaScript puro.

Também vale lembrar que o TypeScript pode criar vícios de código que não necessariamente refletem de maneira igual em um código JavaScript puro (o TypeScript não faz checagem de tipos em tempo de execução, por exemplo). Similar ao que ocorria antigamente com desenvolvedores “JavaScript” que só sabiam programar em jQuery, o uso exclusivo do TypeScript pode levar à perda de familiaridade com JavaScript puro, o que definitivamente não é bom, já que inconsistências no código gerado pelo TypeScript sempre podem ocorrer, e nestes casos é necessário conhecimento em JavaScript (que é o que de fato roda nos navegadores) para mitigar os possíveis problemas. Além disso, é sempre bom reforçar que a linguagem de programação da web sempre foi (e provavelmente continuará sendo) JavaScript, e não suas variantes.

Sendo assim, vale reforçar que apesar de ser extremamente interessante, o TypeScript definitivamente não deve ser considerado como um item obrigatório no seu projeto. Cabe a você como desenvolvedor avaliar o custo-benefício para o seu caso específico. E como toda ferramenta, ele deve ser usado apenas quando você julgar ser uma alternativa apropriada para o trabalho.