Apresentando o Type Safety em seu projeto JavaScript? Pense de novo

Apresentando o Type Safety em seu projeto JavaScript? Pense de novo

Atualização - 1º de fevereiro de 2017

Eu ouvi vários contra-argumentos sobre segurança de tipo em JavaScript desde que publiquei este artigo e, embora eu ainda acredite que muitos projetos não exigem o uso de um superconjunto de JavaScript digitado, admito que fui muito precipitado em publicar este artigo. Alguns casos de uso apropriados, subsequentemente, chamaram minha atenção:

  • Glimmer, o mecanismo de renderização de baixo nível por trás do Ember, foi escrito em TypeScript para promover sites de chamadas monomórficas, auxiliando no desempenho quando executado por V8 e potencialmente outros mecanismos JavaScript
  • O Visual Studio Code se beneficia do TypeScript devido ao tamanho do projeto; dado que é distribuído como um aplicativo de desktop, ter uma base de código em vez de reconciliar pacotes individuais no momento da compilação é, na minha opinião, uma opção sensata
  • O Sect (reconhecidamente um projeto meu, então há um viés potencial aqui!) É escrito em TypeScript para que os consumidores possam escrever jogos grandes e modulares para a web, enquanto reduzem de forma confiável erros de tempo de execução resultantes de erros ortográficos e outros problemas que surgem como resultado de JavaScript natureza dinâmica

Além disso, percebi que escrever bibliotecas menores em TypeScript e publicá-las com as definições de tipo geradas no momento da construção simultaneamente permite sua integração perfeita com projetos de JavaScript digitados e tradicionais, dando aos desenvolvedores uma escolha tecnológica mais ampla.

No entanto, para o bem da posteridade, aqui está o artigo original na íntegra.

Hoje, encontrei um artigo sobre o lançamento de JS ++, que afirma “corrigir a falta de segurança de tipo do JavaScript”. Curiosamente, já temos TypeScript, ST-JS e Scala.js, que ajudam os desenvolvedores a atingir o mesmo objetivo.

Antes de iniciar este discurso, permita-me destacar três pontos importantes:

  • Já escrevi um tutorial sobre como estabelecer um projeto TypeScript simples. Eu vejo a hipocrisia, mas minhas opiniões mudaram desde que o publiquei, há mais de um ano
  • Tipagem forte e tipagem estática são paradigmas vitais. O primeiro fornece transparência sobre as entidades representadas no código de alguém, seus relacionamentos e a funcionalidade que se espera que forneçam, enquanto o último é uma rede de segurança importante em tempo de compilação em sistemas complexos. Eu venho de uma formação C #, então tenho experiência em primeira mão com isso
  • Também adoro JavaScript, devido às suas falhas inerentes, muitas das quais foram corrigidas com ECMAScript 6 e 7

Então, por que geralmente sou contra a digitação estática em JavaScript?

Predominantemente, o que torna o JavaScript uma linguagem tão poderosa é sua natureza fracamente tipada; é trivial implementar ramos de lógica por meio de coerção de tipo e é tão fácil criar instâncias de objeto de um tipo arbitrário. Além disso, a falta de compilação (a menos que se esteja usando um transpiler ou ferramenta de construção como o Babel, por exemplo) torna o desenvolvimento incrivelmente rápido, desde que o código não resulte em nenhum comportamento bizarro. Na minha opinião, é isso que o torna tão poderoso para desenvolvimento de front-end e back-end simples (por exemplo, IoT).

Pessoalmente, acredito que se alguém está desenvolvendo um sistema tão complexo que requer segurança de tipo, deve-se usar uma linguagem que o suporte em seu núcleo; escrever um sistema de orientação, que envolve operações matemáticas complexas, em JavaScript é uma loucura.

Minha principal preocupação com essas ferramentas e superconjuntos JavaScript é que elas compilam para, bem, JavaScript; esses programas são conseqüentemente executados em um contexto dinâmico, portanto, os mesmos efeitos colaterais ainda podem ocorrer. O TypeScript, por exemplo, pode ser digitado estaticamente (ou seja, as informações do tipo são coletadas e analisadas em tempo de compilação), mas deve-se ter total confiança de que o código resultante ainda será executado conforme o esperado. Sim, é claro que mesmo as linguagens tipadas estaticamente são geralmente compiladas para uma linguagem de nível inferior, que então é tipicamente interpretada, mas essas linguagens de destino foram certamente projetadas com a digitação como um cidadão de primeira classe; como exemplo, o compilador JIT da Microsoft para .NET ainda implementa a verificação de tipo em tempo de execução de sua linguagem intermediária antes de compilar para o código nativo.

Além disso, ao empreender o desenvolvimento de front-end, ainda tenho a mentalidade de que JavaScript deve ser usado para complementar soluções HTML e CSS, por exemplo, adicionar classes a elementos, fazer chamadas HTTP para serviços de back-end etc. Enquanto a web amadureceu em termos de estruturas para autoria aplicativos maiores baseados em IU (para sua informação, escrevi aplicativos maiores com React.js e vanilla JS também; adoro os dois), prefiro manter meu JS o mais leve possível. Eu entendo que isso nem sempre é uma possibilidade na realidade, mas se os sistemas de back-end servirem como a verdade de origem para a lógica de negócios fundamental, o código de front-end se tornará mais leve e menos redundante; a esse respeito, quais benefícios um sistema de tipos trará?

Seguindo meu ponto sobre o tamanho do software de front-end, meu trabalho atual envolve escrever aplicativos da web concentrados para cada preocupação do sistema abrangente; ao contrário de um grande aplicativo de página única para nossa loja, que contém uma visualização de lista de produtos, uma visualização de detalhes do produto e uma visualização de jornada de compra, temos os respectivos aplicativos baseados em Node.js para eles. Evidentemente, esta é uma prática recomendada em termos de acoplamento fraco e resiliência, mas do ponto de vista do código, permite focar mais facilmente na implementação de uma área de nosso front-end.

Meu argumento final é este; JavaScript é realmente tão difícil de aprender? Como eu disse antes, o ECMAScript 5 em si é uma linguagem falha; os diferentes padrões de invocação de função e como eles afetam a palavra-chave `this` e a falta de escopo de bloco, por exemplo, podem tornar isso difícil para iniciantes. No entanto, com o ECMAScript 6, além da abundância de recursos incríveis por aí, é fácil de superar e estar ciente desses problemas. Por que não simplesmente ignorar o intermediário e aprender o idioma diretamente?

Concluirei dizendo que sou um fã de todas as abordagens de digitação, mas algumas se adaptam a certos cenários mais do que outras. Se o JavaScript funciona melhor para a maioria dos softwares de front-end, dada sua onipresença nas equipes de desenvolvimento e seus projetos, então certamente ele não precisa de um superconjunto. Além disso, há um monte de linguagens que são inerentemente seguras de tipo, então pare de reinventar a roda!