Sobesin — Frontend Developer/
TypeScript
TypeScript/
Что такое Typescript? Зачем нужен? Какие есть плюсы и минусы?
Search

Что такое Typescript? Зачем нужен? Какие есть плюсы и минусы?

🎯 Зачем спрашивают
  • Проверить, понимает ли кандидат, зачем вообще нужен TS, или «просто пишет, потому что в проекте так решили».
  • Отличить разработчика, который знает TS как инструмент, от того, кто осознанно использует его для снижения рисков.
  • Увидеть, понимает ли человек trade-offs: TS помогает, но не серебряная пуля.
  • Проверить кругозор: знает ли про альтернативы и ограничения (runtime-валидация, Flow, PropTypes и т.п.).
  • Cпособен ли кандидат аргументировать перед бизнесом («почему мы выбираем/не выбираем TS»).
 
📝 Ответ
Коротко: TypeScript — это надмножество JavaScript, добавляющее статическую типизацию и дополнительные возможности компиляции, что привносит в экосистему JS контрактное программирование.
 
⚠️
TS ≠ контрактное программирование
TS ≠ классическое «contract programming» (design by contract). TS ближе к static type checking. TS добавляет статическую типизацию и позволяет задавать явные контракты между частями кода
Плюсы и минусы:
✅ Плюсы
❌ Минусы
Простые синтаксические ошибки, контрактные ошибки обнаруживаются еще на эта разработки (до запуска тестов, например)
Высокий порог входа, если не писали ранее на языках со строгой типизацией
Позволяет проектировать сервисы/модули/компоненты на уровне описания интерфейсов и типов
Дженерики, utility-типы (если использовать их не в тривиальных случаях) кажутся отдельным языком программирования, что может запутать и усложнить чтение кода https://www.youtube.com/watch?v=9lqmJSwb2HA https://www.youtube.com/watch?v=YDTZpQrBXjc
Если контракт описан хорошо, то избавляет от необходимости заходить в код и читать реализацию
Сложность настройки и инфраструктуры. Нужно ставить компилятор, настраивать конфиги, иногда — дополнительный сборщик. Интеграция с существующим JS-кодом не всегда гладкая, особенно в больших проектах. Требуется постепенная точечная миграция
ㅤ
В рантайме TS вас не спасет. Все проверки типов «сгорают» при компиляции. Если данные приходят извне (например, из API), то без ручной валидации zod, io-ts ошибки могут попасть в рантайм
ㅤ
Долгое время компиляции в больших проектах На очень больших кодовых базах компиляция может замедляться. Иногда приходится использовать tsc --incremental или переходить на swc, esbuild.
ㅤ
Всратые ошибки. Порой TS выдает абсолютно нечитаемую простыню, которая дает ответы на все вопросы, кроме главного — “а в чем ошибка, твою мать?”. Есть даже расширение для VSCode, например, которое пытается сгладить ситуацию и сделать ее чуть более читаемой. Из-за чего приходится бороться с языком, а не с проблемой
Подробнее: Далее прозвучит мое субъективное мнение. При всех своих минусах, TypeScript является де-факто стандартом индустрии. Если ваша команда умеет писать на TS включает строгие настройки ts конфига, то разрабатывать можно гораздо быстрее и, что самое главное, с удобствами. Есть специалисты, пропагандирующие использование нативного JS, а TS — только лишь для декларации типов, если сильно хочется (.d.ts файлы).
Лично я не обладаю настолько высокой компетенцией, чтобы разрабатывать большие приложения, совместно с командой от 20-50 человек, на нативном JS. Да и речь чаще идет о backend разработке на JS, где цена ошибки в разы выше, чем на frontend части.
 
 

Альтернативы

Другие надмножества/варианты JS
  • Flow (от Facebook)
    • Тоже статическая типизация поверх JS.
    • Проиграл TS в экосистеме и сейчас мёртв.
  • Elm
    • Функциональный язык для фронтенда, компилируется в JS.
    • Очень строгая система типов, «ловит» почти всё ещё на этапе компиляции.
    • Минус: нишевый, меньшая экосистема.
  • ReasonML / ReScript
    • Язык на базе OCaml, компилирующийся в JS.
    • Синтаксис OCaml-подобный, многим непривычен
    • Более строгая типизация, чем в TS, но совсем другая парадигма.
    • Часто рассматривают как инструмент для “сильной части кода” (основная логика, критичные части), а не для всего фронтенда.
 
Классические типизированные языки, компилирующиеся в JS
  • Dart
    • От Google, статически типизированный.
    • Используется во Flutter, но есть и веб-сборка в JS.
  • PureScript
    • Функциональный язык, близкий к Haskell.
    • Очень строгая система типов, но высокий порог входа.
  • Kotlin/JS
    • Можно писать на Kotlin, компилировать в JS.
    • Полезно, если команда уже использует Kotlin (например, в Android).
Библиотеки и системы для типизации в JS
  • JSDoc + проверка типов в VSCode/TS
    • Можно писать обычный JS и добавлять JSDoc-комментарии.
    • VSCode и TS-компилятор будут проверять типы без .ts файлов.
    • Удобно для проектов, где не хотят «жёстко» переходить на TS.
  • PropTypes (в классовых компонентах React) [Deprecated]
    • Проверка типов только в рантайме (во время выполнения).
    • Гораздо слабее TS, но проще для небольших проектов.
Runtime-валидация
  • Zod / io-ts / runtypes
    • Библиотеки, которые дают runtime-проверку типов.
    • Можно использовать вместе с TS или без него.
    • Полезно, если важна именно валидация входных данных, а не статическая проверка кода.
 
⚖️ Компромиссы
  • ✅ Снижение багов и ускорение разработки на зрелых проектах.
  • ❌ Рост стоимости входа и поддержки (особенно на старте и в маленьких командах).
 
🔎 Встречные вопросы
  • Чем отличаются типы и интерфейсы в TS?
  • Как мигрировать JS-проект на TS?
  • Как ускорить компиляцию на большом проекте?
 
🚩 Красные флаги
  • TS спасает от всех ошибок
  • TS = то же самое, что JSDoc
  • Минусы? Да вроде нет
 
🛠 Практика
 
📚 Источники / ссылки