O que a proposta de sintaxe de tipo ES da Microsoft significa para JavaScript

0
15


O JavaScript poderá em breve obter sua própria sintaxe de tipo se uma proposta apresentada pela Microsoft e outros desenvolvedores no início deste ano se tornar parte do padrão ECMAScript. A iniciativa planeja adicionar suporte a “tipos como comentários” à linguagem JavaScript, permitindo que os desenvolvedores anotem código com informações de tipo que serão usadas por outros componentes do ecossistema.

a sintaxe

A sintaxe proposta fica assim:

function sayAge(name: string, age: number) {
    console.log(`${name} is ${age} years old.`);
}
 
sayAge("JavaScript", 26);

Será familiar para quem já usou o TypeScript antes, o superconjunto de JavaScript escrito da Microsoft. O TypeScript ganhou ampla adoção em todo o setor; esta nova proposta visa trazer alguns de seus benefícios para o mundo do JavaScript em geral.

Qual não é a proposta?

Se aprovada, esta proposta permitirá que você escreva JavaScript perfeitamente válido com as anotações de tipo mostradas acima. Ele será aceito por runtimes JavaScript, como navegadores da Web, Node.js e Deno que aderem ao padrão ES.

No entanto, a proposta não estende de fato a linguagem JavaScript. Suas anotações de tipo serão exatamente isso: metadados inertes que não têm efeito no compilador JavaScript ou no tempo de execução do seu código. Uma chamada de função como a seguinte funcionaria em tempo de execução:

function sayAge(name: string, age: number) {
    console.log(`${name} is ${age} years old.`);
}
 
// "age" is a string when it should be a number, but this is still allowed
sayAge("JavaScript", "twenty");

A ideia é fornecer uma nova sintaxe de tipo que seja oficialmente suportada, mas completamente ignorada pelos mecanismos. A única mudança para implementações diz respeito ao reconhecimento e remoção de anotações de tipo onde quer que sejam usadas.

A proposta buscaria estabelecer suporte anotando os tipos de parâmetros, variáveis ​​e propriedades de classe. Eu também gostaria de adicionar um interface palavra-chave, operadores de afirmação como ! S asfui a ? modificador para marcar os tipos como opcionais. A intenção é que todos esses elementos reflitam o TypeScript; No entanto, como em qualquer proposta do Estágio 0, o resultado final pode funcionar de forma diferente.

Qual é o ponto?

Se as anotações de tipo não mudarem seu programa, a pergunta óbvia é se vale a pena tê-las. A proposta argumenta “sim” devido à capacidade da sintaxe de encurtar os tempos de iteração e reduzir a sobrecarga em torno das cadeias de ferramentas JavaScript modernas.

Atualmente, escrever código seguro para tipos exige que você use TypeScript, um tipo diferente de linguagem que adiciona dependências ao seu projeto e requer uma etapa de compilação manual. Esse código pode então ser passado por outras ferramentas, como um empacotador e transpilador de módulo, antes que o JavaScript final seja produzido para distribuição. Ele se soma a uma cadeia de ferramentas complexa com várias peças móveis.

Embora o JavaScript seja uma linguagem inerentemente vagamente tipada, os benefícios da tipagem forte agora são amplamente reconhecidos pela comunidade. Isso é evidente pelo impulso em torno do projeto TypeScript. A digitação estática também foi a líder clara na pergunta “recurso ausente” da pesquisa State of JS de 2021.

Adicionar uma sintaxe de tipo ao JavaScript permitiria que você obtivesse alguns dos benefícios do TypeScript sem precisar compilar seu código. Isso simplifica a configuração e a manutenção do projeto, ao mesmo tempo em que desenvolve JavaScript para se alinhar melhor às práticas modernas de desenvolvimento.

Nos últimos anos, mais código começou a migrar para uma abordagem “puro JavaScript”. O declínio dos navegadores legados torna a transpilação menos necessária do que antes: a maioria das implementações modernas oferece suporte completo para recursos como classes, funções de seta, variáveis ​​com escopo de bloco e async/await. O JavaScript ainda possui um sistema de módulos completo que funciona em todos os mecanismos, incluindo navegadores.

Apenas alguns anos atrás, uma longa cadeia de ferramentas foi requeridos para que você possa escrever esses recursos em seu código com confiança, ele funcionará nos dispositivos dos usuários. Hoje, os desenvolvedores podem ignorar com segurança esses processos de compilação, revertendo para o modelo JavaScript original de arquivos de referência com <script> rótulos

Os tipos são uma das poucas áreas restantes do ecossistema JavaScript que não são adaptadas à própria linguagem. Ame-os ou odeie-os, não há como negar que os tipos se tornaram parte integrante do desenvolvimento JavaScript para muitas equipes e projetos. A proposta de sintaxe reconhece formalmente esse fato. Ele tenta fornecer um grau de suporte de tipo para JavaScript sem quebrar o código existente ou impor verificações de tipo de tempo de execução que afetam o desempenho.

O que os caras realmente deveriam fazer?

O papel de um “tipo” varia entre os idiomas. O denominador comum está na capacidade de um tipo de expressar o tipo de dados que uma determinada variável conterá. Significados, capacidades e comportamentos adicionais são então sobrepostos a essa base.

Em linguagens compiladas estaticamente tipadas como C# e Java, os tipos são aplicados em tempo de compilação. É impossível compilar um programa quando você tem incompatibilidades de tipo em seu código. Em linguagens interpretadas com tipagem forte opcional, das quais o PHP é um exemplo, os tipos são impostos em tempo de execução: o programa gera um erro quando o tipo de um valor é incompatível com o contexto em que é usado.

Um debate ativo dentro da comunidade JavaScript tem sido até que ponto o mandato de qualquer sistema de tipo embutido deve se estender. Esta proposta limita seu papel ao elemento mais fundamental, uma simples documentação do tipo esperado de um valor. Isso se alinha bem com a posição do TypeScript como uma sintaxe de tipo apagável que é ignorada em tempo de execução.

O objetivo desse modelo é fornecer aos desenvolvedores feedback instantâneo sobre possíveis bugs enquanto eles escrevem o código. Você pode aprender sobre problemas de tipo ao escrever JavaScript regular em um IDE compatível. Se desejar, você também pode usar uma ferramenta auxiliar como TypeScript, um analisador estático ou um pacote para auditar sua fonte sob demanda. Isso pode bloquear uma implantação em seus pipelines de CI quando ocorrer um problema de tipo.

A sensação atual é que esses recursos são suficientes para alinhar o JavaScript com as necessidades mais comuns dos desenvolvedores. Recursos encontrados em outras linguagens, como introspecção e reflexão, geralmente não são necessários no ecossistema JavaScript, em parte porque os desenvolvedores se acostumaram com a abordagem de apagamento do TypeScript.

A alternativa existente: Docblocks

Vale a pena notar que já existe algo semelhante à sintaxe de anotações limpas proposta: tags JSDoc familiares são comumente usadas para adicionar detalhes de tipo ao código JavaScript bruto:

/**
 * @param name {string}
 * @param age {number}
 */
function sayAge(name, age) {
    console.log(`${name} is ${age} years old.`);
}

Os comentários JSDoc são suportados por várias ferramentas populares. No entanto, eles não são uma parte padronizada da linguagem e exigem que você misture detalhes de sua operação de código (seus tipos esperados) com a documentação centrada em humanos que compreende o restante do docblock.

A sintaxe JSDoc também é muito detalhada. Além dos nomes de tags obrigatórios, normalmente requer a repetição de elementos que já existem em seu código, como os nomes de parâmetros no exemplo acima. Se você modificar um parâmetro na assinatura da função, lembre-se de alterar também a tag JSDoc.

A nova proposta de sintaxe pode ser funcionalmente equivalente aos docblocks, mas oferece uma experiência muito mais simplificada. Os tipos ficam ao lado de seus destinos como parte de sua origem, e não em um bloco de documentos que você precisa criar e manter separadamente.

Que segue?

A equipe e os coautores do Microsoft TypeScript, incluindo Bloomberg, Igwalia e vários colaboradores independentes, apresentaram a proposta do Estágio 0 na sessão plenária do TC39 de março de 2022. Desde então, a proposta progrediu para o Estágio 1. No entanto, a aceitação ainda está longe, e a implementação dentro dos motores pode não durar “anos”.

O objetivo geral desta proposta é equilibrar a cauda longa do código JavaScript não tipado com a demanda atual por uma experiência de desenvolvimento com tipagem mais estática. O uso de uma sintaxe excluída totalmente opcional garante compatibilidade com versões anteriores, mas aumenta a possibilidade de que seja ineficaz em promover a adoção e solidificar o ecossistema. O debate em torno disso parece crescer com novas opiniões e perspectivas à medida que a proposta avança no caminho dos padrões.