Executando verificação de segurança...
2

Javascript nativamente tipado

Tipagem, ame ou odeie, ela tem muitas vantagens: melhor DX (através do preenchimento automático intellisense), melhor documentação de código, menos erros que consomem tempo, melhor leitura do código. Seus benefícios superam em muito seu custo, então por que algumas pessoas ainda o evitam? Uma palavra: Typescript . Você precisa configurá-lo e garantir que suas ferramentas estejam funcionando corretamente, o que pode adicionar uma camada de frustração a qualquer projeto.

TC39 é o responsável pelas especificações do Javascript - eles ajudam a manter e evoluir a definição do JS.
Recentemente, eles moveram a proposta de Anotações de tipagem para o Estágio 1 (de 4), o que significa que é hora de especular amplamente sobre o impacto e as implicações desse recurso!

Isso significa a morte do Typescript? Não, simplesmente permitirá um código JS mais limpo e confiável para projetos que não planejam usar TS ou que desejam usar os dois em conjunto.

Como será a tipagem no JS nativa se esta proposta for aprovada?

Seria muito próximo do que temos atualmente com Typescript e Flow, ou seja:

interface Person {
  name: string;
  age: number;
}

let x: string;
x = "hello";
x = 100; // <-- Type 'number' is not assignable to type 'string'. 

function equals(x: number, y: number): boolean {
  return x === y;
}

Essas anotações não impedirão que você passe uma string ou qualquer outro tipo de variável como parâmetro. Eles serão ignorados no tempo de execução e estão lá apenas como diretrizes que podem ser usadas por verificadores de tipo de terceiros, como seu IDE.
O argumento para tipagem estrita tem seu lugar nesta discussão na minha opinião. Em sua proposta atual, esses tipos são apenas anotações de tipo, algo que já temos graças ao JSDoc. Então fica a pergunta: por quê?

Qual é o ponto?

Estamos em uma situação estranha: Javascript é uma das únicas linguagens que nos faz escrever em uma outra linguagem Typescript para depois transpilar para voltar novamente para Javascript. Essas camadas adicionam complexidade a qualquer projeto, portanto, quanto mais ferramentas adicionarmos a nossa maleta de ferramentas, melhor.
A necessidade do Typescript cria uma forma de monopólio sobre as ferramentas disponíveis atualmente, onde cada um deles precisa evoluir com o TS para não ficar para trás. O (State of the Octoverse 2022) [https://octoverse.github.com/2022/top-programming-languages] mostra a popularidade impressionante do Typescript em 2022, o que significa que essa necessidade de evoluir se torna quase obrigatória para seus linters, bundlers, etc.
Ter esse recurso já empacotado com nosso querido Javascript apenas o tornará um pacote mais completo e nos ajudará a diminuir o óbvio inchaço de ferramentas que estamos enfrentando atualmente.

O que você acha? Você se veria usando esse recurso se ele fosse lançado? Quais são os riscos que vêm à sua mente, especialmente se você for um ávido usuário do Typescript?

Texto original: Christopher Kade

Carregando publicação patrocinada...
2

Consigo imaginar o TS sempre vindo na frente com certas mudanças para 'testa-las' com a comundade antes do js adotar. Não imaginaria a morte do TS, mas uma constante corrida onde o TS desbrava o caminho antes de consolidar no JS. Isto é bem saudável na minha visão, pois o TS teria mais margem de manobra para errar e mudar sem quebrar toda a internet.

Mas adoro a idéia do js ter a tipagem própria, anos na linguaguem e ver isso acontecendo agora é bem legal. Marco na história.