Em 2017-2019, houve um aumento significativo no TypeScript. Isso aconteceu por razões óbvias. Há muita coisa boa nesse idioma. Quase metade
dos entrevistados da pesquisa
State of JavaScript de 2018 já experimentou o TypeScript e planeja escrever no futuro. O TypeScript é bastante popular, mas vale a pena usar em projetos de software em larga escala?
Neste material, é feita uma tentativa estrita, com base nos indicadores numéricos e na experiência prática do autor, de analisar o efeito do uso do TypeScript no desenvolvimento de grandes projetos.
Sobre o crescimento do TypeScript
O TypeScript é uma das linguagens que mais crescem. Atualmente, é o idioma principal daqueles compilados em JavaScript. Aqui estão os dados do TypeScript do Google Trends.
Dados do Google Trends 2014-2019 sobre a dinâmica de popularidade do TypeScriptA seguir, são apresentadas
informações do GitHub que refletem o interesse dos programadores no trabalho de desenvolvimento de várias linguagens de programação.
Dados do GitHub sobre o crescimento das linguagens de programação em termos do número de colaboradoresOs indicadores acima são impressionantes, indicando a crescente popularidade do TypeScript, que não deve ser subestimada. Mas deve-se notar que o TS ainda está longe de ser reconhecido como a principal linguagem do ecossistema JavaScript. Se o ecossistema JavaScript for comparado ao oceano, o TypeScript será uma grande onda nesse oceano. Aqui está uma comparação de JavaScript (linha vermelha) e TypeScript (linha azul) de acordo com o Google Trends.
Dados do Google Trends para 2014-2018 sobre a dinâmica da popularidade do JavaScript e TypeScriptE aqui estão as
informações do GitHub sobre as principais linguagens de programação usadas para criar repositórios em 2008-2018.
Dados do GitHub sobre o número de repositórios criados usando várias linguagens de programaçãoVocê pode ver que, pelo número de repositórios, o TypeScript não está entre os cinco principais idiomas.
Note-se que em 2018 houve um ponto de virada na história do TypeScript, e em 2019 essa linguagem será usada em muitos projetos reais. Se você é um desenvolvedor de JavaScript, em tais condições, simplesmente não terá escolha. A decisão de usar o TypeScript em um projeto em que você precisa trabalhar já será tomada sem levar em conta sua opinião. Você não precisa ter medo de aprender e usar o TypeScript.
No entanto, se você decidir quem linguagem usar em um projeto, precisará ter uma compreensão realista dos pontos fortes e fracos do TypeScript. Ao tomar decisões, você precisará entender se a escolha do TypeScript terá um efeito bom ou ruim no projeto.
Minha experiência sugere que o TypeScript tem seus prós e contras, mas não se pode dizer que seu uso, em geral, tenha um impacto positivo nos projetos. O TypeScript atraiu muitos desenvolvedores, e muitas coisas estão relacionadas a essa linguagem que eu, que a testamos na prática, realmente gosta. Mas você tem que pagar por tudo.
Antecedentes
Eu vim para o JavaScript do mundo das linguagens estaticamente tipadas - como C / C ++ e Java. No começo, era difícil me adaptar à digitação dinâmica adotada no JavaScript, mas assim que me acostumei, me senti como uma pessoa que chegava à saída de um longo túnel escuro e via a luz. A digitação estática tem muitos recursos positivos, mas o mesmo pode ser dito sobre a digitação dinâmica.
Nos últimos anos, mergulhei periodicamente de cabeça no desenvolvimento do TypeScript. Como resultado, ganhei mais de um ano de prática TypeScript. Liderei várias equipes grandes usando o TypeScript como idioma principal. Isso me permitiu avaliar o impacto do TypeScript no desenvolvimento de grandes projetos e comparar projetos semelhantes com projetos semelhantes que usavam JavaScript comum.
Em 2018, os aplicativos descentralizados poderão
decolar . A maioria desses aplicativos usava contratos inteligentes e soluções de código aberto. Ao desenvolver aplicativos para a Internet de valor, os erros nos programas podem custar dinheiro aos usuários. Agora, mais do que nunca, é importante escrever um código confiável. Como esses projetos geralmente são de código aberto, achei que o que usamos no desenvolvimento do TypeScript é bom, porque isso facilitará o trabalho de outras equipes do TypeScript com nossas soluções e, ao mesmo tempo, garante a compatibilidade nosso código com projetos que usam JavaScript.
Durante o uso prático do TypeScript, comecei a entender melhor as vantagens e desvantagens dessa linguagem. Também ficou claro para mim que tipo de escolha o TypeScript poderia ter em um projeto de software. Lamento dizer que a experiência com o TypeScript não foi tão bem-sucedida quanto eu queria. Se o TypeScript não for significativamente aprimorado, não escolherei essa linguagem para outro projeto em larga escala.
Pontos fortes do TypeScript
O TypeScript, a longo prazo, ainda me parece um desenvolvimento positivo. Quero amar esse idioma e ainda gosto de alguns de seus recursos. Espero que os desenvolvedores do TypeScript e seus proponentes vejam críticas construtivas neste material, e não ataques infundados a essa linguagem. Os desenvolvedores do TypeScript podem corrigir algumas de suas deficiências e, se o fizerem, posso repetir minha análise da eficácia dessa linguagem e obter resultados diferentes.
A digitação estática pode ser muito útil, pois ajuda a documentar funções, facilita a compreensão do código e reduz a sobrecarga cognitiva do programador. Por exemplo, eu costumo achar o sistema do tipo Haskell funcionando, sem exigir muito tempo e esforço, conveniente e discreto. Mas, às vezes, até o sistema flexível do tipo Haskell e seus tipos mais sofisticados dificultam o trabalho. Por exemplo, tente digitar um transdutor usando Haskell ou TypeScript. Isso não é fácil, e talvez o resultado seja um pouco pior do que o seu equivalente não digitado.
Gosto do fato de que as anotações TypeScript, se interferirem, podem ser opcionais. Gosto do fato de o TypeScript usar tipografia estrutural e de haver algum suporte para a inferência de tipo (embora existam muitas oportunidades de aprimoramento nessa área).
O TypeScript oferece suporte a interfaces reutilizáveis (ao contrário de declarações de tipo internas). As interfaces podem ser usadas de diferentes maneiras para anotar APIs e assinaturas de funções. Uma única interface pode ter muitas implementações. As interfaces são um dos melhores recursos do TypeScript e eu gostaria que algo semelhante aparecesse no JavaScript comum.
Um dos pontos fortes do TypeScript é o seu kit de ferramentas. Por exemplo, o uso de um editor adequado (como Atom ou Visual Studio Code), para o qual são criados plug-ins TS de alta qualidade, coloca à disposição do desenvolvedor as melhores ferramentas no ecossistema JavaScript. Os desenvolvedores de outros plug-ins devem estudar os plug-ins TS e pensar em como, usando as idéias incorporadas neles, eles podem melhorar seu desenvolvimento.
Análise de desempenho TypeScript
Agora vou avaliar o TypeScript para vários indicadores, colocando notas na faixa de -10 a 10. Isso ajudará você a entender melhor o quão bom (ou ruim) o impacto que o TypeScript pode ter em projetos grandes.
Se a pontuação no indicador exceder 0 - isso indica o impacto positivo do TypeScript no projeto. Se a pontuação for menor que 0, isso indica um impacto negativo. Um valor de classificação de 3-5 pontos indica um efeito bastante forte. 2 pontos indicam exposição média. 1 ponto é um efeito relativamente fraco.
Os números com os quais continuarei operando são difíceis de medir com precisão. Nas minhas avaliações, serei, até certo ponto, subjetivo. Mas tentei fazer essas estimativas para que, da maneira mais realista possível, revelassem os prós e os contras do uso do TypeScript em projetos reais.
Todos os projetos que analisei, dando notas, continham mais de 50 mil linhas de código. Eles foram o resultado do trabalho de vários programadores por vários meses. Um desses projetos é baseado no Angular 2, que utilizava o TypeScript. Foi comparado a um projeto semelhante escrito usando Angular 1 e JavaScript regular. Todos os outros projetos são baseados em React e Node usando TypeScript. Eles foram comparados com projetos semelhantes que usavam JavaScript simples. Alguns indicadores, como densidade de insetos, foram estimados apenas aproximadamente. Todas as equipes que trabalham nos projetos consistiram em desenvolvedores TypeScript experientes e iniciantes. Todos os membros dessas equipes tiveram a oportunidade de interagir com mentores mais experientes, que os ajudaram a se adaptar no campo do desenvolvimento do TypeScript.
Devido ao pequeno tamanho da amostra, os dados objetivos que eu tenho são muito heterogêneos, há muito ruído neles, portanto, com base neles, é impossível fazer certos julgamentos objetivos que poderiam ser feitos com base em números suficientemente precisos e sem arriscar muito cometer um grande erro. Um projeto JavaScript mostrou uma densidade de erros na produção que era 41% menor que um projeto TypeScript comparável. Em outra comparação, um projeto TypeScript mostrou uma densidade de erro 4% menor que um projeto JavaScript comparável. Nesse caso, é óbvio que o número de erros que atingiram o estágio de lançamento do produto é muito mais afetado não pelo uso do TypeScript no projeto, mas pela presença ou ausência de outras medidas para garantir a qualidade do código. Isso distorce os indicadores a tal ponto que se torna impossível usá-los.
Uma gama tão ampla de indicadores objetivos levou ao fato de eu decidir não usá-los, focando no ritmo de implementação das capacidades do projeto e nas observações que indicam as áreas do ciclo de vida do projeto nas quais a maior parte do tempo era gasta. Abaixo, analisando os indicadores, falaremos sobre isso com mais detalhes.
Como minha análise tem um forte componente subjetivo, é necessário considerar a possibilidade de imprecisões na interpretação dos indicadores (isso é refletido no diagrama). Mas as conclusões gerais dessa análise podem fornecer uma imagem realista do que você pode esperar do uso de um projeto TypeScript.
Análise de desempenho TypeScriptJá posso ouvir as objeções em relação às baixas classificações dos benefícios do TypeScript e, francamente, não posso rejeitar completamente essas objeções. O TypeScript, de fato, fornece ao programador alguns recursos muito úteis e poderosos. Não há dúvida sobre isso.
Para entender o motivo das classificações positivas comparativamente baixas e raras na minha análise, você deve entender com o que estou comparando o TypeScript. Isso não é "apenas JavaScript", mas JavaScript e ferramentas projetadas para um desenvolvimento efetivo nessa linguagem.
Considere os indicadores mostrados no diagrama.
▍ Ferramentas do desenvolvedor
O Toolkit é o meu recurso TypeScript favorito, que é provavelmente a maior vantagem prática do uso dessa linguagem. Graças a ferramentas de alta qualidade, a carga cognitiva no desenvolvedor é reduzida. À sua disposição, há dicas sobre os tipos de interfaces. No processo, em tempo real, são detectados erros em potencial. Se nada desse tipo acontecesse ao desenvolver JavaScript simples usando bons plug-ins, eu daria ao TypeScript uma classificação positiva mais alta. Mas, no nosso caso, 0 pontos é algo que você já pode usar ao programar em JavaScript, ou seja, com o qual estamos comparando o TypeScript, já está em um nível bastante alto.
A maioria dos advogados do TypeScript parece não entender muito bem com o que o TypeScript está competindo. O ponto é que a escolha das ferramentas não é uma decisão sobre o uso do TypeScript ou JavaScript sem nenhuma ferramenta auxiliar. Trata-se de escolher entre o TypeScript e todo o rico ecossistema de ferramentas de desenvolvimento JavaScript. As ferramentas de preenchimento de código e detecção de erro para JavaScript comum fornecem de 80 a 90% do que normalmente são considerados pontos fortes do TypeScript. Isso acontece, por exemplo, ao usar ferramentas para
conclusão de código, ferramentas para
tipos de saída e
linters . Ao usar o sistema de inferência de tipo e ao aplicar os parâmetros de função padrão que apareceram no ES6, o desenvolvedor tem à sua disposição dicas muito semelhantes às disponíveis ao trabalhar no código TypeScript com anotações de tipo.
Um exemplo de preenchimento automático de código JS regular com inferência de tipoHonestamente, se você usar as configurações padrão para fornecer dicas de tipo, absolutamente não precisará anotar o código TypeScript. Essa é uma excelente técnica para reduzir o número de construções de sintaxe auxiliar, que são uma das desvantagens do TypeScript.
As ferramentas usadas para escrever código TypeScript são talvez um pouco melhores, parecem mais holísticas, mas tudo isso não é suficiente para dar ao TypeScript uma classificação muito mais alta e para cobrir as deficiências dessa linguagem.
▍ Documentação da API
Outro grande benefício do TypeScript é a melhor documentação da API. De fato, podemos dizer que a documentação da API sempre corresponde ao estado do código-fonte. A documentação pode até ser gerada com base no código TypeScript. Para esse indicador TypeScript, também é possível atribuir uma nota mais alta - se, ao programar em JavaScript, não é possível usar algo como
JSDoc ,
Tern.js e muitas ferramentas para gerar documentação. Pessoalmente, como não sou fã do JSDoc, o TypeScript na minha análise sobre esse indicador é bastante apreciado.
Deve-se notar que, mesmo usando a melhor documentação incorporada ao código no mundo, não se pode prescindir de documentação real; portanto, é justo dizer que os recursos do TypeScript têm mais probabilidade de expandir os recursos de compilação de documentação existentes do que substituí-los.
▍ Segurança do tipo
Ao comparar o tipo de segurança de TS e JS, como se viu, não é possível revelar uma diferença especial. Os proponentes do TypeScript geralmente falam sobre os benefícios da segurança de tipo, mas não se pode dizer que a
segurança de tipo reduz significativamente a densidade de erros na produção. Este é um ponto importante, pois o uso da revisão de código e do TDD tem um sério impacto na solução de problemas (apenas o uso da técnica
TDD reduz os erros em 40 a 80%). Se você combinar o TDD com uma análise da arquitetura dos projetos, com a verificação das especificações e com as revisões de código, poderá obter uma redução de mais de 90% na densidade de erros. Muitas dessas técnicas (TDD em particular) podem ajudá-lo a encontrar os mesmos erros que podem ser detectados com o TypeScript, bem como muitos erros que o TypeScript não pode detectar.
Aqui nós damos alguns cálculos
deste estudo . O máximo teórico de erros "publicamente disponíveis" que podem ser detectados pelo TypeScript é de cerca de 15%. Erros "públicos" são erros que sobrevivem à fase de desenvolvimento do projeto e terminam em um repositório público.
O estudo mencionado monitorou erros que eram conhecidos antecipadamente. Isso incluía o conhecimento de quais linhas de código foram alteradas para corrigir erros, enquanto o problema e sua solução potencial eram conhecidos antes da digitação do código. Isso significa que mesmo o conhecimento da existência de erros não permitiu, usando o TypeScript, detectar 85% dos erros "públicos".
Por que o TypeScript não consegue detectar tantos erros? Por que estou dizendo que 15% dos erros detectados são o máximo teórico do TypeScript? Para começar, é importante notar que, de acordo com o estudo em questão, erros nas especificações levam a aproximadamente 78% dos erros nos repositórios públicos do GitHub. A incapacidade de formular claramente as especificações dos programas ou a incapacidade de implementar corretamente as especificações levam ao tipo mais comum de erro. Isso leva automaticamente ao fato de que a maioria dos erros nos projetos de software TypeScript não pode ser detectada ou evitada. Os autores do estudo, entre outras coisas, identificam e classificam erros que não são detectados pelo TypeScript. Aqui está um gráfico de barras com informações sobre esses erros.
Erros que não são detectados pelo TypeScriptO exemplo "StringError" é um erro que ocorre se uma string é usada onde uma string é necessária, ou seja, erros nos tipos não ocorrem, mas o conteúdo dessa string causa um erro (por exemplo, pode haver uma URL incorreta). Usando a análise estática, você pode identificar alguns desses erros examinando o conteúdo de seqüências de caracteres e usando descrições desse conteúdo. Mas isso dará apenas a perspectiva de corrigir uma pequena fração de uma pequena porcentagem de erros. Como resultado, estamos dizendo que é improvável que o TypeScript possa detectar mais de 15 a 18% dos erros.
Aqui pode parecer que 15% já é bastante. Por que o TypeScript não pode detectar uma porcentagem muito maior de erros?
Como existem muitos erros que não podem ser detectados por meio da digitação estática, seria irresponsável recusar o uso de outros métodos de controle de qualidade, como revisão de código e TDD. Portanto, é injusto confiar no fato de que o TypeScript será a única ferramenta de algum projeto usada para lidar com erros. Para perceber realisticamente o indicador considerado de nossa análise da eficácia do TypeScript, vale a pena calcular o número potencial de erros detectados pelo TypeScript, depois que os erros detectados por outros métodos forem excluídos de seu número.
Suponha que seu projeto contenha 1000 erros se você não tomar nenhuma medida para lidar com erros. Depois que o projeto foi testado corretamente, o número potencial de erros que podem atingir a produção foi reduzido para 100. Agora, para ver as possibilidades reais do TypeScript, vamos ver quantos desses erros podem ser detectados usando-o. Como cerca de 80% dos erros não podem ser detectados usando o TypeScript, e considerando que, em teoria, todos os erros detectados usando o TypeScript podem ser detectados usando outros métodos, como a metodologia TDD, chegaremos bastante generosamente e assumiremos que o TypeScript detectará outros 8% de erros. Além disso, procedemos da suposição de que não encontramos cerca de metade dos erros que o TypeScript detecta de outras maneiras. O resultado é o seguinte:
- Um projeto no qual as medidas de controle de erro não são aplicadas contém 1000 erros.
- Usando medidas para combater erros não-TypeScript, foram detectados 900 erros.
- Após verificar o projeto usando o TypeScript, restaram 92 erros. Isso significa que, graças à implementação do TypeScript, outros 8 erros foram detectados.
, , TDD, , TypeScript- , , . . TypeScript . TypeScript, .
, TypeScript, TypeScript 15% . — 150 1000. , , TypeScript, 900 . , , , TypeScript - . TypeScript , , , 908 1000 (, , , , TypeScript).
. , 30-80% . :
, , , , , , , TypeScript. : TypeScript . , . .
, , - TypeScript. TypeScript, ?
▍ JavaScript - (New JS Features, Compile to Cross-Browser JS)
TypeScript 0, JavaScript. , Babel JavaScript , , , .
TypeScript JavaScript. , . JavaScript , , , , TypeScript , . , , TypeScript «».
▍ (Recruiting)
, State of JavaScript, TypeScript , 33.7% TypeScript. 5.4% TS , , 13.7% , . TS- 20%, , . — , (, , , ).
, - , TypeScript . . , TypeScript .
▍ , (Setup, Initial Training)
, . , JavaScript, TypeScript- 2-3 , 6-8 . , , , , , , TypeScript, , .
▍ (Missing Features)
, , . TypeScript JavaScript. TypeScript , . , JavaScript- , , . , , , TypeScript .
TypeScript TypeScript. , , , . , , TypeScript- . , , , , .
▍ (Ongoing Mentorship)
TypeScript, . , , , . TypeScript -. , , , , , .
, TypeScript- , , , , . , , , , , .
. . , TypeScript-, - , . « » — , , . , — , TypeScript .
▍ , (Typing Overhead)
, , , . — TypeScript, . . , , .
, , . , , , . , , , .
, . , , .
, TypeScript « ». Haskell , . TypeScript, , , , , .
, TypeScript- . — , TypeScript- , , , , . TypeScript- , , . , , — .
« » . , .
« » — , . « » — .
« » — TypeScript. :
- . «» ( — Haskell).
- , , , . TypeScript- , , , , , , . , , TypeScript-, Stack Overflow.
TypeScript, , . , , .
, TypeScript , , .
TypeScript , . TypeScript , , , . TypeScript, TypeScript- , TypeScript.
, TypeScript , , « » TypeScript . , TypeScript-, .
TypeScript, , , , — , , TypeScript. TypeScript . , — , , TypeScript.
.
TypeScript , «JavaScript, ». : «JavaScript, ».
! TypeScript.
