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

TypeScript — это надмножество JavaScript, которое добавляет в язык необязательную статическую типизацию и другие функции. Он был разработан Microsoft и набирает популярность среди разработчиков благодаря своей способности улучшать качество кода и уменьшать количество ошибок.

Итак, давайте углубимся в вопрос о 5 миллионах долларов. Стоит ли вообще использовать TypeScript?

Недостатки:

Не использую его вообще

Хотел начать с самого большого недостатка. Но этот недостаток связан с тем, как люди его используют, а не с самим языком. Я уверен, что у вас есть или вы увидите кодовые базы, в которых есть тонны любогоключевого слова, разбросанного вокруг, чтобы избежать TypeScript. Некоторым это может показаться безвредным, но дело в том, что при этом вы также отключаете ванильный JavaScript intelli-sense и средства проверки проблем для этого объявления.

Решения для этого просты; устраивая им ад в обзорах кода. И, пытаясь объяснить им, почему мы вообще используем TypeScript.

Отношение сигнал шум

Я должен начать с краткого объяснения того, что такое отношение сигнал/шум:

Вы можете ссылаться на signal как на значимую информацию. Другими словами, это то, чего вы хотите достичь.

И вы можете относиться к шуму как к ненужной, не относящейся к делу информации. Другими словами, это информация, которая не влияет на смысл или назначение кода и может затруднить его понимание. Шум может включать такие вещи, как ненужные комментарии, сложный синтаксис или ненужные правила или ограничения. Это может отвлекать от полезной, значимой информации в коде и затруднять его чтение и понимание.

TypeScript — это надмножество JavaScript, что означает, что вы можете писать простой код JavaScript в TypeScript без каких-либо дополнительных изменений. Это означает, что отношение сигнал-шум в TypeScript может быть таким же, как и в JavaScript по умолчанию.

Однако это не всегда так, потому что, во-первых, это противоречит цели использования TypeScript в первую очередь, а во-вторых, кодовые базы часто применяют правила против этого, такие как явное объявление типов, обязательные идентификаторы доступа для классов, обязательные возвращаемые типы, и тому подобное.

Таким образом, с такими правилами отношение сигнал/шум растет очень быстро по сравнению с ванильным JavaScript. Вы пишете все больше и больше, чтобы добиться того же.

Практически отсутствует во время выполнения

Система статической типизации TypeScript означает, что типы проверяются на уровне кода, а не во время выполнения. Это означает, что ошибки типов обнаруживаются в процессе разработки, а не во время выполнения кода.

Эффективность TypeScript зависит от того, насколько точно объявления типов соответствуют поведению кода во время выполнения. Невыполнение этого требования может привести к дополнительным проблемам, с которыми вам придется иметь дело.

Преимущества:

Дает хорошее представление о пути выполнения кода

Путь выполнения кода относится к порядку, в котором код выполняется компьютером. Путь выполнения кода определяет последовательность шагов, которые выполняет компьютер для выполнения задач, указанных в коде. Понимание пути выполнения кода важно для написания эффективного и безошибочного кода.

Если вы занимаетесь программированием не менее шести месяцев, вы, вероятно, хорошо понимаете путь выполнения кода. Однако, если вы новичок в программировании, вам может быть трудно понять концепцию пути выполнения кода. В этом случае использование TypeScript при написании JavaScript может быть полезным, так как TypeScript предупредит вас о любых проблемах с порядком выполнения кода в каждом блоке кода. Это может быть ценным учебным пособием, даже если вы работаете с ванильным JavaScript, поскольку оно помогает вам более полно понять путь выполнения кода.

Кроме того, понимание пути выполнения кода приведет к написанию более надежного кода, а написание надежного кода часто идет рука об руку с написанием тестируемого кода.

Облегчает рефакторинг

В больших репозиториях JavaScript рефакторинг превращается в настоящий ад. Потому что не на что полагаться, чтобы найти то, что сломано после изменения какой-либо переменной или функции или чего-либо, кроме старого доброго Cmd+F или CTRL+F. Со временем это начинает раздражать, и вы часто ломаете то, что работало до рефакторинга.

С TypeScript, когда условие типов написано правильно, рефакторинг кажется несколько более безопасным. Вы не беспокоитесь о том, что что-то сломаете, поскольку TypeScript поможет вам в случае конфликта типов.

Совместимость с браузером

С TypeScript, не дай Бог, если нам по какой-то причине понадобится ориентироваться на IE11, это действительно легко сделать. Вы можете написать ES2022, а TypeScript может преобразовать его в ES3 или какой-либо другой код, соответствующий спецификации, при его создании. Однако, за некоторыми исключениями, TypeScript не может преобразовать все.

Следующие изменения и Intellisense

Благодаря TypeScript мы можем писать интерфейсы и типы для объектов, массивов и функций. Во-первых, это упрощает отслеживание изменений в объекте или массиве. Во-вторых, с IntelliSense мы можем правильно ссылаться на свойство внутри объекта, не сомневаясь и не нуждаясь в исправлении имени свойства из-за того, что оно было написано неправильно в первый раз.

В заключение, TypeScript предлагает как преимущества, так и недостатки по сравнению с JavaScript. С одной стороны, он добавляет дополнительную статическую типизацию и другие функции, которые могут улучшить качество кода и уменьшить количество ошибок. Это также может быть полезным обучающим инструментом для понимания пути выполнения кода. Однако это также может усложнить процесс разработки и увеличить отношение сигнал/шум, что потребует написания большего количества кода для достижения тех же результатов, что и в ванильном JavaScript.

В конечном счете, использовать TypeScript или нет, зависит от конкретных потребностей и целей вашего проекта, а также от предпочтений и навыков вашей команды разработчиков.