Nos resultados da Pesquisa de Desenvolvedores 2020, uma das estatísticas mais acompanhadas é a Linguagem Mais Amada. Como tem sido há vários anos, Rust é o número um. Mas chegando no número dois é TypeScript, um superconjunto fortemente digitado de JavaScript, afiando Python por um fio de cabelo. Queríamos descobrir o que o TypeScript o torna tão amável, então entramos em contato com Ryan Cavanaugh, o principal líder de engenharia para a linguagem TypeScript na Microsoft. Ele foi generoso o suficiente para se sentar e responder nossas perguntas. Sem mais delongas, aqui estão nossas conversas, editadas levemente para clareza.

P: Há quanto tempo você está na equipe TypeScript?

A: Comecei na equipe TypeScript cerca de seis meses antes do nosso lançamento inicial, em fevereiro de 2012. Estou trabalhando nisso há oito anos.

Q: Interessante, tão perto do início. Você se lembra por que a equipe veio com TypeScript, por que você queria lançar algo assim?

A: Quando entrei para a equipe, havia muitas pessoas na Microsoft que queriam desenvolver o JavaScript no que chamamos de "escala de aplicativos". Equipes como TFS e Office queriam construir grandes aplicativos JavaScript. Muitas dessas pessoas tinham familiaridade com línguas estaticamente digitou: C++, C#, Java, esse tipo de coisa. Eles queriam ter essa digitação estática disponível tanto para escalabilidade conceitual quanto para a ferramentaria.

Os especialistas em idiomas da Microsoft olharam para a situação e disseram, bem, poderíamos tentar escrever uma nova linguagem como as pessoas tinham feito antes. Existem projetos como script#, que pega C afiado e transforma-o em JavaScript, ou linguagens como CoffeeScript que diziam, e se JavaScript tivesse uma sintaxe diferente? Mas o que eles decidiram em vez disso foi apenas pegar JavaScript e adicionar tipos estáticos em cima disso.

Na época, JavaScript estava experimentando um renascimento do crescimento, onde eles estavam adicionando recursos à língua novamente pela primeira vez em muito tempo. As pessoas queriam usar esses novos recursos legais, como funções de seta e classes, e não queriam esperar que todos os navegadores os adotassem. Eles queriam ser capazes de usar esses recursos imediatamente. Acho que essas foram as três coisas que o TypeScript ofereceu antecipadamente: digitação estática para fins de erro, aproveitando essas informações do tipo estático para ferramentas e fornecendo os recursos JavaScript de amanhã, hoje.

Q: Houve um ponto em que você viu um ponto de adoção sem retorno? Havia algo que surgiu onde as pessoas estavam como, oh, sim, nós fazemos TypeScript agora?

A: Oh, foi definitivamente o Google anunciando que eles iam usar TypeScript com Angular. Isso está meio perdido para o tempo agora. Mas se você olhar para os gráficos do TypeScript, literalmente qualquer gráfico — estrelas do GitHub, downloads, pedidos de tração — você pode ver o ponto exato quando o anúncio do Angular saiu. E o gráfico só muda. Nunca olha para trás. Você não pode mais ver aquela pequena curva na curva porque a curva continuou. Foi um verdadeiro ponto de inflexão. E eu acho que tem sido interessante que as pessoas pensaram na época que o TypeScript seria exatamente o que as pessoas angulares usam e não muito mais. Não acabou sendo o caso. Obviamente, ainda somos populares entre os devs angulares. Mas isso foi um verdadeiro construtor de impulso para nós.

P: Em nossa pesquisa de desenvolvedor mais recente, TypeScript é a linguagem número dois mais amada,subindo nasfileiras. Por que acha que as pessoas gostam tanto?

A: Hein? Porque é ótimo!

Q: Eu acho que precisamos de uma resposta que possamos defender objetivamente.

A: Fundamentalmente, JavaScript recebe um rap ruim como uma língua, mas é realmente muito divertido trabalhar com. Ele permite que você seja um pouco dinâmico às vezes e um pouco mais intencional às vezes. É apenas uma ótima linguagem funcional. Mas a falta de verificação do tipo estático realmente inibe a capacidade das pessoas de escrever coisas que elas podem estar confiantes funcionarão antes de executá-lo.

O TypeScript sustenta essa última vantagem áspera no JavaScript e lhe dá algo que é muito divertido de trabalhar e funciona em todos os lugares. Eu acho que se o TypeScript fosse uma linguagem que foi construída em cima de uma linguagem menos universal ou uma linguagem menos divertida, eu não acho que seria tão bem sucedido. É realmente pegar algo que é ótimo e torná-lo melhor.

Q: Parece que a digitação estática é uma espécie de ter um momento agora. Eu vi um monte de comentários sobre apreciar o pato digitando em Rust, as dicas em Python. Por que acha que a digitação estática é tão popular agora?

A: Eu acho que porque as pessoas tentaram construir grandes aplicações sem ele e viram como é doloroso. Quero dizer, a mesma coisa está acontecendo com hack no Facebook, onde eles estão adicionando tipos ao PHP. Então eu acho que as pessoas perceberam que você pode escrever um pequeno programa sem digitação estática muito facilmente, mas você rapidamente atingiu um limiar onde, sem ele, as coisas se tornam muito dolorosas. É muito difícil argumentar quando você está tentando mantê-los e adivinhando digitar e tal.

Acho que a minha coisa favorita que vejo são as pessoas na Internet dizendo: 'Eu fiz essa grande refatoração no TypeScript e eu estava refatorando por três horas. E então eu corri o meu código e funcionou da primeira vez. Em uma linguagem dinâmica, isso nunca, nunca aconteceria. Há um elemento muito satisfatório para ser feito quando o verificador tipo diz que você está feito. Isso pode ser apenas 85% preciso. Mas isso é muito melhor do que zero. É uma maneira muito melhor de se desenvolver, especialmente durante uma grande reformulação como essa.

Q: Eu vi algumas pessoas resistentes à digitação estática. Você acha que há um lugar para a digitação mais dinâmica?

A: Eu acho que sim. Quero dizer, é um grande mundo de programação lá fora. Eu não acho que você está errado em não gostar de tipos estáticos. Acho que é uma preferência pessoal. Há certamente programas onde a digitação estática vai ficar no seu caminho. Isso é uma coisa importante para nós. também fornecemos ferramentas para JavaScript, e ainda achamos que javaScript é uma maneira totalmente válida de se desenvolver. Eu diria às pessoas, se os tipos estáticos não são adequados para você, tanto para o seu estilo de programação ou para o problema que você está trabalhando, basta ignorá-lo. Está tudo bem, não se preocupe. Está tudo bem, está tudo bem. Não me ofenderei. Se alguém consegue um aplicativo de 30 mil linhas que faz seu trabalho sem tipos estáticos, estou muito impressionado. Isso parece muito difícil. Mas parabéns para as pessoas que fazem isso funcionar.

Python é do mesmo jeito. Muito poucas pessoas têm anotações do tipo Python trabalhando, mas Python é incrivelmente popular. Acho que os dados falam por si só — acho que Python é o número três na pesquisa (nota: É, mas por um cabelo). Garanto que uma proporção muito pequena desses desenvolvedores Python tem tipos estáticos. Seja qual for o seu domínio de problemas, isso pode ser o melhor para você.

Q: Eu sei que estamos chegando no 25º aniversário de Java. JavaScript está conosco há algum tempo também. E agora, TypeScript. O que há sobre as tendências que vimos na última década, passando de trabalhar offline para trabalhar na web, para trabalhar no celular, que fazem JavaScript e agora TypeScript tais ferramentas desejáveis?

A: Acho que é simplesmente um efeito de plataforma. Se houvesse alguma linguagem de programação que fosse veiculada em todas as máquinas e no navegador, essa seria a linguagem de programação mais popular hoje. Quero dizer, eu falo muito bem do JavaScript, mas eu honestamente acho que o fato de que ele decolou e entrou nos navegadores e depois entrou na área de trabalho e no servidor - esse é o jogo todo ali. Não acho que seja algo com a linguagem, é apenas a sua posição.

P: Certo, a capacidade de aprender uma linguagem que você vai ser capaz de usar não importa onde você acabe, a menos que você seja um desenvolvedor COBOL trabalhando em um sistema governamental ou algo assim.

A: Sim. A nuvem, eu acho, é um grande aspecto disso, onde você quer código que executa plataformas Linux, plataformas Windows, Mac. Muitas linguagens de programação tentaram e falharam em entregar intencionalmente a execução entre plataformas. Talvez não tenha falhado, mas não conseguiu a aceitação que gostaria. O JavaScript começou na parte inferior — ou talvez no topo — como uma linguagem de nível muito alto que só funciona em navegadores e depois funcionou até que fosse algo que você pudesse executar em um nível mais baixo interagindo com o sistema de arquivos.

P: Então, o que vocês da equipe TypeScript estão fazendo para manter o TypeScript como uma linguagem bem amada?

A: Estamos sempre olhando para o que o feedback do usuário está nos dizendo, o que as pessoas estão pedindo, olhando para o que são as bibliotecas populares no ecossistema JavaScript. Tudo isso nos ajuda a descobrir qual é o próximo recurso certo para adicionar ao idioma.

O vue está chegando. Há muitos para listar, na verdade. Mas à medida que as diferentes estruturas de interface do usuário ou bibliotecas subjacentes de manipulação de dados se tornam mais populares, precisamos ter certeza de que o idioma é capaz de representá-los. O GraphQL está ficando popular. Bem, nosso sistema de tipo pode expressar com precisão as coisas que você precisa fazer com o GraphQL? Há alguma brecha aí?

Só queremos ter certeza de que estamos representando o ecossistema JavaScript como ele é, porque em última análise, se as pessoas querem usar a nova tecnologia JavaScript legal, mas não funciona bem com o TypeScript, eles vão abandonar o TypeScript antes de abandonar o JavaScript, certo? É por isso que você está aqui. Você quer escrever programas que fazem coisas, não apenas satisfazer um verificador de tipo. Então eu acho que isso é a coisa mais importante para nós.

Mas também queremos crescer intencionalmente. As linguagens populares de programação, como você disse, têm vinte e cinco, trinta e trinta e cinco anos agora. E estamos no oitavo ano. Se temos apenas um quarto das características que realmente precisamos, ainda estamos no ritmo.

P: Na maioria das vezes, o TypeScript é transpilado em JavaScript. Com deno,é uma língua de primeira classe. O que você acha de esforços como esse? E você acha que os navegadores vão fazer TypeScript primeiro?

A: Deno é super legal. Eu amo que alguém construiu essa tecnologia e está vendo o que aconteceria com ela. Eu acho que o caso do navegador é realmente interessante porque parece que faz sentido. Então, toda vez que eu ando cinco passos à frente na minha cabeça, tudo quebra para mim.

Então, para mim, é como, OK, você vai servir TypeScript para o cliente. E então os clientes podem interpretar o TypeScript. Bem, se você não quer verificar o tipo no arquivo que você enviou, então não há realmente nenhum ponto. Tirar as anotações do tipo é um processo muito mecânico e não há muito valor lá. Você pode enviar mapas de origem ou qualquer outra coisa, mas isso é mais uma experiência de depuração de diagnóstico. Então, entramos neste modo onde estamos enviando isso como TypeScript para que ele possa ser digite verificado pelo cliente.

Minha primeira pergunta é, por que esse é o trabalho do cliente? Porque você empurra este código TypeScript para o servidor, e espero que ele digite verificações no ponto em que você fez isso. Se não, seria estranho considerar por que você teria feito isso. E, novamente, cenários de desenvolvimento são apenas uma besta totalmente diferente aqui. Eu gostaria de ver mais investimento no espaço de desenvolvimento para perguntas como, faria mais sentido ter isso?

Mas de qualquer forma, vamos dizer que continuamos e digitamos a verificação do cliente. Bem, você não pode realmente começar este processo de verificação tipo até que você puxou todas as suas dependências dentro E então você vai acabar enviando arquivos .d.ts que realmente não fazem nada. E como o arquivo .d.ts entrou no seu servidor?

Não vou dizer que isso nunca vai acontecer, mas acho que há muito mais espaço para tecnologias como o que você vê com "create-react-app", onde há um servidor web ao vivo para fins de desenvolvimento, verificando os tipos em segundo plano à medida que serve o JavaScript transpilado na hora. Tipo, esse é um modelo fantástico que torna todas as minhas objeções totalmente discutíveis porque o tipo de verificação está acontecendo em um momento mais lógico. Talvez haja algum espaço para um plug-in do navegador. Mas esse modelo também é um pouco confuso, porque, em última análise, sua tag 'scripts' vai puxar um arquivo .js, a menos que de repente todos os navegadores em todos os lugares suportem o TypeScript. Isso é o que você vai ter que fazer.

Torna-se uma questão de se você está depurando ou carregando, digamos, a produção HTML que faz referência aos arquivos .js. Onde no processo nós realmente obter o arquivo .ts em vez disso? Nunca diga nunca. Mas para mim é uma situação não tão cedo. Deno é completamente sua própria coisa porque lá é um novo tempo de execução. Então esse cenário faz muito mais sentido para mim, pelo menos para ser digitar durante a primeira vez que você executar um script e ter certeza de que você tem alguns ambientes compatíveis.

P: Qual é o status agora da equipe da Microsoft? Quanto cresceu desde que você se juntou e quão grande é?

A: O tempo todo que trabalhamos nisso, tivemos entre quatro e oito engenheiros compiladores principais, um ou dois PMs, e quatro a zero testadores dedicados. Isso tem sido muito constante. Temos crescido a equipe um pouco mais intencionalmente ultimamente.

Historicamente, tivemos uma equipe principal de compiladores e, em seguida, outra equipe trabalhando no lado visual studio das coisas, porque integrar-se em um grande produto como Visual Studio acaba por ser uma quantidade muito grande de trabalho. Mas algumas melhorias arquitetônicas do lado VS liberaram algum poder de engenheiro por lá. Então, estamos roping nessa equipe para nos ajudar com refatoração e ir para definição e esse tipo de coisa. Mesmo tamanho de equipe no geral, exceto que agora vamos ter mais pessoas trabalhando nos principais serviços de compilação que você vê no repo GitHub.

P: Você poderia me dar uma pequena perspectiva fora da Microsoft — onde você vê pessoas ajudando você a construir isso de maneiras diferentes? Falamos sobre Deno e o que ele faz com o TypeScript. Onde você vê outras pessoas ajudando a construir esse ecossistema?

Somos totalmente dependentes do ecossistema para fazer um produto que funcione em um ambiente integrado. Então, seja webpack ou plugins como ts-loader ou como trabalhamos com rollup ou Parcel ou... nomeie seu empacotador, certo? Isso é tudo muito complicado.

Não estamos em um nível que nos permitiria possuir essa experiência. E nós não queremos. A comunidade deve impulsionar a forma como o TypeScript é subsumido nesses processos de construção maiores e no ecossistema maior como um todo. À medida que o JavaScript constrói pipeline se expande e se torna mais complexo, vemos pessoas intensificando e fornecendo essa funcionalidade. Isso pode ser TypeScript e 'create-react-app' ou como o TypeScript se integra com coisas como Vue. Só queremos ter certeza de que estamos construindo as coisas que só nós sabemos construir e, em seguida, ajudar os outros com coisas que só eles sabem como construir. Alguns marcos atrás, trabalhamos especificamente com o pessoal do ts-loader para obter uma boa implementação de referências de projeto indo para lá.

O número de coisas no ecossistema JavaScript continua crescendo. Em vez de aumentar a equipe, esperamos apenas crescer a comunidade para apoiar o TypeScript em todos esses cenários. Também estamos vendo como podemos ser um pouco mais inteligentes sobre a obtenção de contribuições externas no TypeScript. O principal desafio que vemos é que adicionar recursos à base de código TypeScript é realmente fácil e corrigir bugs é realmente difícil. As pessoas estão muito mais animadas para adicionar recursos do que corrigir bugs porque é divertido. Quem pode culpá-los? Descobrir o que podemos fazer sobre isso e encorajar as pessoas a nos ajudar nas coisas com as quais precisamos de mais ajuda seria um desafio para a comunidade. Não vou lá fora dizer que preciso de mais trabalho de graça. As pessoas podem vir a abrir o código com o que estão aqui para oferecer. Fantástico. Mas isso é algo que eu adoraria fazer mais intencionalmente.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.