Desde sempre desenvolvedores de software enfrentam problemas de compatibilidade e performance de seus softwares, o desafio é imenso. Pois, além da preocupação com o hardware do dispositivo que o software irá rodar, ainda existem problemas com o S.O (Sistema Operacional) do dispositivo.
No desenvolvimento de aplicações multi-plataforma, as preocupações são ainda maiores, pois é preciso criar soluções específicas para cada S.O e hardware. Em desenvolvimento web, encontramos os problemas do desenvolvimento multi-palataforma, dispositivos, sistemas operacionais e navegadores extremamente distintos.
Nos tempos atuais, quando falamos de navegadores esses problemas estão cada vez mais simples de resolver, por conta de que a tendência é que eles tenham uma base gradualmente mais reaproveitável, um exemplo disso, são os navegadores e softwares baseados em Chromium, que compartilham a mesma base de código.
Com o decorrer dos anos a evolução tecnológica se faz evidente, trazendo dispositivos com telas cada vez menores ou gigantes com acesso a internet, ou seja, que interagem com tecnologias web. Temos extremos onde é possível ter o acesso a um mesmo Site a partir de um relógio inteligente com display de 1,3 polegadas ou de uma televisão inteligente de 85 polegadas, perceba que não estamos falando apenas de tamanhos extremamente distintos, mas também de desafios de acessibilidade, compatibilidade, UX e UI.
Há 20 anos atrás esses problemas eram inimagináveis, e não se tem duvidas sobre isso, pois não existia a necessidade ou possibilidade de acessar um Site via relógio ou de uma televisão. Nessa época o muita gente só estava preocupada em acessar o ICQ via Internet Discada em um Monitor de Tubo.
“Na minha época programávamos em ActionScript dentro do Netscape“ — algum desenvolvedor ancião.
E por que falamos tanto de compatibilidade e reaproveitamento se ainda nem começamos a falar de TypeScript ? Com a evolução da tecnologia, temos uma maior complexidade dentro dos softwares, a base de código de um software esta cada vez mais complexa e difícil de manter, e sem duvidas, precisamos de compatibilidade, padronização, reaproveitamento e a organização trabalhando juntas. E é aqui que o TypeScript entra.
O que é TypeScript?
TypeScript é uma linguagem de programação mantida pela Microsoft. Ela é composta por um super conjunto de JavaScript e adiciona “Tipagem” estática opcional a linguagem.
TypeScript foi desenhado para o desenvolvimento de grandes aplicações e “transforma” tudo isso para JavaScript, de maneira com que se perde muito pouca performance em troca de muita produtividade e organização, além de ter toda compatibilidade do JavaScript, já que tudo que é “transformado” não passa de JavaScript.
“O que é um super conjunto de JavaScript? O que é “Tipagem” ?“ — Eu, 2015
O que é um super conjunto de JavaScript?
Um super conjunto ou superset de JavaScript se refere a que temos um JavaScript incrementado ou melhor, tunado. Dispõe sempre da ultima versão do ECMAScript disponível, ou seja, ao instalar a ultima versão do TypeScript você terá acesso aos últimos recursos disponíveis no JavaScript, e não menos importante temos uma linguagem 100% compatível com JavaScript, independente da versão.
O que é “Tipagem” no TypeScript?
“Tipagem” é um termo abrasileirado para “typing”, em linguagens de programação ela tem o papel de identificar “coisas” com o intuito de facilitar a documentação, organização e identificação de modelos de dados. E no TypeScript não é diferente, temos a implementação de interface, type, decorator e enum, além do class herdado do JavaScript, que possui melhorias como extends e implements.
No exemplo abaixo utilizando interface, temos uma função que recebe apenas um parâmetro de um determinado tipo.
Primeiro vamos definir o que o objeto “pessoa” deve conter:
Em seguida criamos uma função que recebe o objeto pessoa, e o escreve no console:
Caso eu tente passar um parâmetro incompatível o Transpiler/Linter irá me retornar uma mensagem dizendo que o parâmetro está incorreto:
Sendo assim, temos a possibilidade de documentar nosso código, e quando a aplicação é grande, isso faz toda a diferença.
Empiricus
Dentro da Empiricus temos diversos projetos que englobam JavaScript, e a minha vontade era de que todos tivessem utilizado TypeScript desde o seu inicio. Demos nosso primeiro passo dentro do TypeScript a partir de 2019 em um projeto do squad do ecommerce, o Checkout.
Falando de um Checkout podemos esperar pouca complexidade, já que teoricamente ele serve apenas para “finalizar” os pagamentos, certo ? Nem sempre, pelo menos no nosso caso, temos alta complexidade de código dentro do Checkout o que torna o uso do TypeScript ainda mais atrativo. Pudemos implementar “tipagem” desde o inicio do projeto, então temos todos modelos de dados “documentados” através de classes, interfaces, types e enums.
Desde então todos novos projetos JavaScript do squad do ecommerce foram criados utilizando TypeScript, e com certeza tem nos trazido apenas bons frutos, principalmente pela organização e facilidade de manutenção.
Resistência ao TypeScript
A não implementação do TypeScript não está associado apenas a curva de aprendizado, mas também pelo receio de quebrar algo que já funciona. Esse foi um dos principais motivos de eu não ter começado a utilizar o TypeScript ainda antes.
Quando comecei a estudar sobre o tema, mais profundamente em 2016, especificamente quando o Angular 2 passou a adota-lo, encontrei 3 pontos principais para NÃO utilizar TypeScript, e eles eram:
1. Existem alternativas
Flow.js
Flow.js te dá a possibilidade de checar em tempo de desenvolvimento a qualidade do seu código através de “tipagem”.
ReasonML/ReScript (antigo BuckleScript)
ReScript é uma linguagem fortemente inspirada em JavaScript, possui muitas semelhanças com o JavaScript e que roda em cima do ReasonML, e promete entregar um código de alto nível. Porém que exige conhecimento em paradigma funcional.
E de fato são boas alternativas, mas em minha opinião uma é básica demais e a outra complexa demais, de certa forma, claro, isso varia de acordo com a complexidade do projeto. Hoje em dia, não se tem duvidas de que o TypeScript é sim uma das melhores opções para grandes aplicações, senão a com melhor custo x beneficio.
2. Não compatibilidade com o Babel
De fato em 2016 não era possível utilizar TypeScript e Babel em conjunto, o que fazia com que fosse uma escolha arriscada, já que milhares de plug-ins existiam dentro do Babel, porém, isso já não é mais um problema. Visto que, podemos facilmente incluir as duas ferramentas e isso é muito bom para quem tem um projeto JavaScript e quer migrar aos poucos para TypeScript.
3. Projeto grande já existente
Isso é uma preocupação para muitos, porém, já sabemos que babel e TypeScript podem trabalhar juntos. Além disso, sabemos que o TypeScript não passa de um JavaScript “tunado” que “transforma” todo o código em JavaScript normal.
Quer dizer que podemos utilizar JavaScript e TypeScript juntos, sem nenhum problema. A única coisa que precisamos fazer é dizer para as configurações do TypeScript/Linter que queremos que eles não apliquem checagens de Tipos dentro de arquivos JavaScript, assim podemos migrar todo código para TypeScript aos poucos não é mesmo?
Considerações finais
Os motivos para não usar TypeScript me assustaram em 2016, porém enxerguei muitos benefícios a frente disso, porém a maioria desses motivos não são mais validos em 2021, e talvez algum dos motivos que citei podem ter te afastado do TypeScript.
O TypeScript até pode ser considerado uma ferramenta opcional, entretanto tem sido considerado como uma necessidade, especificamente por trazer inúmeros benefícios e poucos ou quase nenhum ponto negativo.
É importante ressaltar que a organização, padronização e compatibilidade de todo software depende exclusivamente da equipe de desenvolvimento, e o TypeScript é uma das melhores opções para facilitar toda essa organização e padronização mantendo toda compatibilidade de um software JavaScript.
