Поиск…


Вступление

Если вы обнаружите, что аргументы для систем типов убедительны вообще, то вы будете довольны TypeScript.

Это приносит много преимуществ системы типов (безопасность, удобочитаемость, улучшенная оснастка) для экосистемы JavaScript. Он также страдает некоторыми недостатками систем типов (сложность и неполнота).

замечания

Достоинства типизированных и нетипизированных языков обсуждались десятилетиями. Аргументы для статических типов включают:

  1. Системы безопасности: типа позволяют много ошибок быть пойманными на раннем этапе, без запуска кода. ТипScript может быть настроен так, чтобы допускать меньше ошибок программирования
  2. Читаемость: явные типы делают код более понятным для людей. Как писал Фред Брукс, «Покажите мне свои блок-схемы и сокрыте свои столы, и я буду продолжать мистифицировать. Покажите мне свои столы, и мне обычно не нужны ваши блок-схемы, они будут очевидны».
  3. Инструментарий: системы типов делают код более понятным для компьютеров. Это позволяет использовать более мощные инструменты, такие как IDE и linters.
  4. Производительность: системы типов делают код более быстрым, уменьшая необходимость проверки типа времени выполнения.

Поскольку вывод TypeScript не зависит от его типов , TypeScript не влияет на производительность. Аргумент для использования TypeScript опирается на три других преимущества.

Аргументы против систем типов включают:

  1. Сложная сложность: системы типов могут быть более сложными, чем описываемая ими среда исполнения. Функции более высокого порядка могут быть легко реализованы правильно, но сложны для ввода . Работа с определениями типов создает дополнительные барьеры для использования внешних библиотек.
  2. Добавленная многословность: аннотации типов могут добавить шаблон к вашему коду, что затрудняет выполнение основной логики.
  3. Более медленная итерация: вводя шаг сборки, TypeScript замедляет цикл редактирования / сохранения / перезагрузки.
  4. Неполнота: система типов не может быть как звуковой, так и полной. Есть правильные программы, которые не разрешает TypeScript. И программы, которые принимает TypeScript, могут содержать ошибки. Система типов не устраняет необходимость в тестировании. Если вы используете TypeScript, вам, возможно, придется подождать дольше, чтобы использовать новые функции языка ECMAScript.

TypeScript предлагает несколько способов решения всех этих проблем:

  1. Добавлена ​​сложность. Если ввести часть программы слишком сложно, TypeScript можно в значительной степени отключить, используя непрозрачный any тип. То же самое верно для внешних модулей.
  2. Добавлена ​​многословность. Это можно частично решить с помощью псевдонимов типов и способности TypeScript выводить типы. Написание четкого кода - это такое же искусство, как и наука: удалить слишком много аннотаций типов, и этот код может быть не более понятным для читателей.
  3. Более медленная итерация: шаг сборки относительно распространен в современной разработке JS, и TypeScript уже интегрируется с большинством инструментов сборки . И если TypeScript поймал ошибку раньше, он может сэкономить вам весь цикл итерации!
  4. Неполнота. Хотя эта проблема не может быть полностью решена, TypeScript смог отображать все более выразительные шаблоны JavaScript с течением времени. Недавние примеры включают добавление отображаемых типов в TypeScript 2.1 и mixins в 2.2 .

Аргументы для и против систем типов вообще одинаково хорошо применимы к TypeScript. Использование TypeScript увеличивает накладные расходы для запуска нового проекта. Но со временем, по мере того как проект увеличивается в размерах и получает больше вкладчиков, надежда состоит в том, что плюсы использования (безопасность, удобочитаемость, инструменты) становятся сильнее и перевешивают минусы. Это отражено в девизе TypeScript: «JavaScript, который масштабируется».

безопасности

ТипScript уловляет ошибки типов в начале статического анализа:

function double(x: number): number {
  return 2 * x;
}
double('2');
//     ~~~ Argument of type '"2"' is not assignable to parameter of type 'number'.

читабельность

TypeScript позволяет редакторам предоставлять контекстуальную документацию:

Контекстная автозаполнение метода строковых срезов

Вы никогда не забудете, будет ли String.prototype.slice (start, stop) или (start, length) раз!

механическая обработка

TypeScript позволяет редакторам выполнять автоматические рефактории, которые знают правила языков.

Переименованный символ, но только в своей области

Здесь, например, Visual Studio Code может переименовывать ссылки на внутреннее foo без изменения внешнего foo . Это было бы трудно сделать с помощью простого поиска / замены.



Modified text is an extract of the original Stack Overflow Documentation
Лицензировано согласно CC BY-SA 3.0
Не связан с Stack Overflow