Коли говорять про еволюцію мов програмування, ім’я Андерса Гейлсберга зазвичай згадують у контексті Turbo Pascal, Delphi та C#. Але за останнє десятиліття саме TypeScript став його найпомітнішим внеском у сучасну веб‑розробку. У розмові на каналі The Pragmatic Engineer Гейлсберг пояснює, чому TypeScript узагалі з’явився, на чому тримався його дизайн і чому справжня причина популярності — не «типи заради типів», а інструменти, які ці типи зробили можливими.
Епоха JavaScript: сила повсюдності й ціна динамічності
До появи TypeScript JavaScript уже фактично став універсальною мовою інтерфейсів. Він працював у кожному браузері, був єдиним реальним варіантом для клієнтського коду і поступово проникав на сервер, у мобільні гібридні застосунки та десктопні оболонки. Саме ця повсюдність створила і можливість, і проблему.
З одного боку, JavaScript був надзвичайно гнучким. Динамічна типізація дозволяла швидко писати код, експериментувати, змінювати структури даних «на льоту». З іншого — у великих кодових базах це оберталося болючою реальністю: неочевидні помилки в рантаймі, складні рефакторинги, крихкі API між командами, які важко перевірити до запуску.
Ключовий виклик полягав у тому, що змінити сам JavaScript було практично неможливо. Будь-яке радикальне розширення мови або новий байткод означали б зламати веб: мільярди рядків коду, мільйони сайтів, десятки реалізацій рушіїв у браузерах. Стандартизація ECMAScript рухається повільно й обережно саме тому, що кожна зміна має зберігати сумісність і не змінювати поведінку існуючих програм.
TypeScript народився як відповідь на це обмеження: як додатковий шар над JavaScript, який дає статичний аналіз і потужні інструменти — але не чіпає рантайм.
Ерасабельні типи: типова система, яка зникає при компіляції
Базова ідея TypeScript звучить майже парадоксально: додати до JavaScript статичну типову систему, яка… повністю зникає до моменту виконання. Саме це мається на увазі під «erasable type system» — типи, які існують лише на етапі розробки й компіляції, а в результаті перетворюються на звичайний JavaScript.
TypeScript-компілятор читає вихідний код, аналізує типи, будує семантичну модель програми, виявляє помилки, але у вихідному JavaScript не залишає жодних типових конструкцій. Немає додаткових структур у рантаймі, немає спеціальних типових об’єктів, немає змін у семантиці виконання. На виході — такий самий JavaScript, який міг би написати розробник вручну.
Це рішення було принциповим з кількох причин.
По‑перше, воно гарантує, що будь-яке середовище, де працює JavaScript, автоматично підтримує TypeScript‑код після компіляції. Не потрібно чекати оновлення браузерів, не потрібно домовлятися з комітетами стандартів. TypeScript не вимагає нового рантайму.
По‑друге, це дозволяє інкрементально типізувати існуючі проєкти. Оскільки TypeScript зберігає семантику JavaScript, можна взяти наявний код, просто перейменувати файли з .js на .ts або .tsx, додати мінімальні анотації — і поступово посилювати типову дисципліну. Немає жорсткого «переписати все з нуля».
По‑третє, ерасабельність типів дає змогу зосередитися на головному: не на тому, як типи поводяться в рантаймі, а на тому, як вони допомагають інструментам розуміти код під час розробки.
Ставка на інструменти: типи як паливо для IDE
Ключова ставка, яку зробила команда TypeScript, полягала в тому, що сама по собі типова система — не самоціль. Справжній виграш у продуктивності з’являється тоді, коли типи стають основою для інструментів: автодоповнення, рефакторингів, навігації по коду, раннього виявлення помилок.
Ця логіка перегукується з попередніми проєктами Гейлсберга. Turbo Pascal свого часу став проривом не лише як компілятор, а як цілісне середовище: редактор, компілятор, рантайм, інтерактивний цикл розробки — все в одному продукті. У TypeScript ця ідея отримала нове втілення: мова і компілятор одразу задумувалися як основа для «розумного» редактора.
TypeScript-компілятор виконує подвійну роль. З одного боку, це звичайний транспайлер, який перетворює TypeScript у JavaScript. З іншого — це language service, сервіс мови, що постійно підтримує семантичну модель кодової бази й відповідає на запити редактора в реальному часі.
Саме ця друга роль і стала тим, що зробило TypeScript настільки привабливим для розробників JavaScript.
Коли редактор запитує «що це за символ?», «куди веде це посилання?», «які властивості має цей об’єкт?», «де ще використовується ця змінна?», він звертається до тієї самої семантичної моделі, яку будує компілятор. Типи — це не просто декларації для компіляції, це джерело правди для всієї IDE.
У результаті розробник отримує:
автодоповнення, яке знає про реальні типи, а не просто підказує за текстовими збігами;
перейти до визначення, яке працює навіть у великих монорепозиторіях;
масштабні рефакторинги, на кшталт перейменування символів, які не ламають код у несподіваних місцях;
помилки типів, що з’являються ще до запуску тестів або відкриття сторінки в браузері.
Ці можливості стали головною причиною, чому TypeScript так швидко набрав популярність у спільноті JavaScript. Розробники приходили не заради абстрактної «строгішої типізації», а заради відчутного щоденного комфорту в редакторі.
Зберегти JavaScript, але зробити його передбачуванішим
Один із фундаментальних принципів дизайну TypeScript — не змінювати рантайм‑семантику JavaScript. Це означає, що будь-який коректний JavaScript‑код є коректним TypeScript‑кодом (хоча й не обов’язково безпомилковим з погляду типів), а поведінка програми після компіляції залишається такою самою.
TypeScript не додає нових конструкцій, які вимагали б спеціальної підтримки в рушіях. Усі розширення синтаксису або трансформуються в існуючі можливості JavaScript, або спираються на вже стандартизовані фічі ECMAScript. Там, де мова пропонує щось додаткове (наприклад, інтерфейси), це існує лише на етапі компіляції й повністю зникає в результаті.
Такий підхід має кілька важливих наслідків для екосистеми.
По‑перше, він знижує бар’єр входу. Розробникам JavaScript не потрібно вивчати новий рантайм чи іншу модель виконання. Вони працюють із тими самими об’єктами, функціями, прототипами, промісами, але отримують додатковий шар безпеки й підказок.
По‑друге, він дозволяє інкрементальне впровадження в командах. Частина проєкту може залишатися на «чистому» JavaScript, інша — поступово переходити на TypeScript. Можна змішувати файли, використовувати декларативні файли типів для сторонніх бібліотек, не переписуючи їхній код.
По‑третє, він зберігає гнучкість JavaScript там, де вона справді потрібна. TypeScript підтримує поступову типізацію: розробник може почати з широких типів на кшталт any, а потім звужувати їх у критичних місцях. Це не спроба перетворити JavaScript на «іншу мову», а радше спосіб зробити його передбачуванішим у масштабі.
Усе це особливо важливо для великих, багаторічних кодових баз, де працюють десятки й сотні розробників. Там, де динамічність JavaScript перетворюється з переваги на джерело технічного боргу, TypeScript дає спосіб навести лад, не розриваючи зв’язок із екосистемою.
Компілятор як сервіс: чому інструменти й мова більше не розділяються
Історія TypeScript підсилила одну тенденцію, яка вже давно визрівала в індустрії: мови програмування й інструменти більше не можна проєктувати окремо. Особливо це стосується мов, які використовуються в масштабних, багатокомандних проєктах.
У минулому компілятор часто сприймали як «чорну скриньку», яка на вході отримує текст, а на виході видає бінарник або байткод. Інструменти — редактори, дебагери, статичні аналізатори — будувалися навколо нього, часто з обмеженим розумінням внутрішньої семантики мови.
TypeScript демонструє іншу модель. Компілятор і language service — це один і той самий механізм, який постійно «живе» поруч із розробником. Він інкрементально аналізує код, оновлює модель проєкту при кожному натисканні клавіші, відповідає на запити IDE. Межа між «компіляцією» і «редагуванням» розмивається.
Цей підхід виявився особливо ефективним саме в JavaScript‑світі, де історично інструменти відставали від того, що було звичним для розробників на C# чи Java. До TypeScript багато хто сприймав слабкі можливості автодоповнення й рефакторингу як «неминучу ціну» за динамічність. TypeScript показав, що можна зберегти рантайм‑модель JavaScript, але підняти рівень інструментів до того, що раніше асоціювався з «серйозними» статично типізованими мовами.
Успіх TypeScript став аргументом на користь того, що дизайн мови має одразу враховувати потреби інструментів. Синтаксис, система типів, модель модулів — усе це повинно бути придатним не лише для компіляції, а й для побудови точних, продуктивних language services. У великих JavaScript‑кодових базах це вже не «приємний бонус», а необхідна умова керованості проєкту.
Чому популярність TypeScript — це перемога інструментів, а не догми типів
Якщо спробувати звести історію TypeScript до однієї тези, вона звучатиме так: розробники JavaScript масово прийняли статичну типізацію не тому, що полюбили типи як такі, а тому, що відчули різницю в інструментах.
Ерасабельна типова система дала змогу побудувати потужний language service, який, у свою чергу, зробив можливими сучасні IDE‑функції для JavaScript‑світу. Збереження рантайм‑семантики JavaScript дозволило впроваджувати TypeScript поступово, без розриву з екосистемою. А ставка на інструменти як на головний канал цінності виявилася правильною: саме вони забезпечили той «мажорний буст продуктивності», на який розраховували автори мови.
У підсумку TypeScript став не стільки «іншою мовою», скільки новим способом писати JavaScript — із передбачуванішою поведінкою, кращою навігацією по коду й меншим числом несподіваних помилок у продакшені. І водночас він став прикладом того, як сучасні мови мають проєктуватися в тісному зв’язку з інструментами, а не як абстрактні формальні системи.
Висновок
TypeScript виріс із дуже конкретного обмеження: JavaScript неможливо радикально змінити, не зламавши веб. Відповіддю стала ерасабельна типова система поверх існуючої мови, яка зберігає її рантайм‑семантику, але відкриває шлях до потужних інструментів.
Ставка на tooling виявилася вирішальною. Компілятор, який одночасно є language service, перетворив редактор на головний інтерфейс до складних кодових баз, а типи — на паливо для автодоповнення, рефакторингу й статичного аналізу. У світі, де JavaScript став мовою за замовчуванням для фронтенду й далеко за його межами, саме це поєднання зручності й сумісності зробило TypeScript одним із найвпливовіших інструментів сучасної розробки.
Джерело
TypeScript, C# and Turbo Pascal with Anders Hejlsberg — The Pragmatic Engineer