TypeScript — це одна з найулюбленіших мов програмування серед розробників. Згідно з дослідженням DOU, вона має найвищі темпи зростання популярності та є лідером уподобань (18% девелоперів обрали б саме цю мову, якби починали комерційний проєкт). Її використовують близько 40% фронтендерів, 5% бекендерів та 16% фулстек-девелоперів. Схоже, що розробники нарешті розібралися в головних перевагах та почали використовувати її за призначенням. Хоча в комʼюніті досі продовжуються суперечки, чи наздожене TypeScript доля CoffeeScript, або ж це і є та сама універсальна мова програмування, на яку всі чекали?
Віктор Галочка, Front-End Developer в Lift, який у свій час перейшов з JavaScript на TypeScript, розповів, як пережити мовний «джетлаг» та не припуститися помилок. У колонці для блогу Genesis Віктор прокоментував, чому TypeScript — це дещо більше, ніж просто анотація типів, а використовувати стилістику JS у проєктах TS — те саме, що колоти горішки девайсами Dyson. А також пояснив, чому забути про 'undefined' is not a function — безцінно. І тільки за це можна пробачити цій мові всі недоліки.
TypeScript — мейнстрим чи необхідність
На початку 2010-х команда Microsoft шукала рішення, яке б дозволило створювати на JavaScript великі та складні програми. На той час JS активно зростала та розвивалася, здобуваючи прихильність розробників. Ця мова давала багато свободи й водночас недостатньо контролю. Щоразу, коли проєкти починали зростати, у командах змінювалися люди, підтримувати код на JS ставало все складніше.
TypeScript був розроблений під керівництвом Андерса Хейлсберга, надихаючись іншими мовами програмування — Java, C# і Objective-C. За словами Райана Кавано, Lead Engineer в Microsoft та одного з творців TypeScript, команда бачила концептуальний розвиток JS саме через статичну типізацію. Попередні експерименти із синтаксисами та створенням нових мов, на кшталт Script# чи CoffeeScript, не вдалися. На цей раз вони вирішили просто взяти JavaScript і додати статичні типи поверх нього.
Так 2012 року зʼявився суперсет TypeScript, який дозволяв розробникам написати більш масштабований і легкий у підтримці код, надаючи такі функції, як статичний тип, інтерфейси, класи та модулі. Це рішення мало покращити якість коду та зменшити кількість помилок у фінальній збірці продукту. А головне — забезпечити більшу надійність, водночас зберігаючи гнучкість і простоту JavaScript.
Спершу спільнота сприйняла TypeScript без ентузіазму. Скоріше за все, мало хто зрозумів, навіщо так ускладнювати звичний JavaScript.
Переломним моментом став 2016 рік, коли вийшла друга версія Angular — популярного фреймворку із відкритим вихідним кодом для створення вебзастосунків. Спочатку він працював на JavaScript, але 2016 року був переписаний на TypeScript, після чого їхня популярність почала пропорційно зростати. Це добре видно у статистиці запитів на Stack Overflow.
За що програмісти люблять TypeScript
З моменту розробки TypeScript активно розвивається. Сьогодні складно уявити великий складний проєкт на фронтенді, написаний на JS без використання TS. Звичайно, хороший розробник може створити чітку архітектуру на JS, але, з мого досвіду, ця мова частіше використовується тоді, коли для задачі критична швидкість. Наприклад, потрібно зробити лендінг і покрутити пару днів рекламу, щоби потестити якусь ідею. У такому випадку недоцільно прописувати його на TS, закладаючи перевикористану логіку та витрачаючи дорогий час розробки.
Головна цінність TypeScript — можливість писати стабільні та масштабовані проєкти. Розробникам, що прийдуть у проєкт пізніше, буде легше розібратися в задумці тих, хто його створював. Коли бачиш прописану сувору типізацію, чітко розумієш, за що відповідає той чи інший компонент. Якщо раптом один із них не відповідає певній задачі, можна створити інший та закласти в це певну логіку, без утворення безладу. У проєкті, написаному на TypeScript малоймовірна ситуація, що в коді одна функція робить половину всього.
Переваги TypeScript:
Має добре реалізовану підтримку ООП, дозволяє розробникам ефективніше використовувати класи, інтерфейси. У результаті код виходить більш структурним та цілісним.
Надає можливість писати модульний код, придатний для повторного використання.
Простіше працювати в команді та підтримувати код, розуміти, яку логіку закладав попередній розробник.
Завдяки редактору IDE є можливість виявляти та виправляти помилки ще під час розробки, а не на етапі тестів чи ще гірше — після релізу.
Підтримка на рівні всіх платформ — у вебі, мобільних та десктоп застосунках.
Інтеграція з різними бібліотеками та фреймворками JavaScript. Крім Angular, може використовуватися з такими популярними інструментами, як React, Vue.
Перехід з JS на TS: як подолати джетлаг
Я починав свій шлях на фронтенді з вивчення JavaScript. Пізніше працював на Angular, де познайомився з TypeScript. Із цього й почалося «доросле» програмування.
Коли довгий час пишеш на JS, а потім різко переходиш на TS, виникає джетлаг. Ти звикаєш до певної швидкості написання коду, а тут усе складніше й довше: підготовка, написання, виправлення помилок, пошук відповідей. Наприклад, коли знаходиш цікаве рішення на Stack Overflow, написане на JS, знадобиться додатковий час, щоби конвертувати його під свій проєкт та вимоги.
Поріг входу до TS вищий. Це той випадок, коли для того, щоби писати на TypeScript, треба знати дві мови — JavaScript та безліч нюансів статичного набору тексту, додаткового синтаксису, дженериків та інтерфейсів. Бажано бути в курсі специфікації, але найголовніше — розуміти концепцію, для чого був створений TS.
Я стикався з багатьма проєктами, написаними джуніорами та мідлами. У момент, коли їх треба було масштабувати, виявлялося, що на старті про це не подумали. Після такого досвіду не виникає питань, навіщо проєкту типізація та інтерфейси.
Тип ‘any’ та локальні пожежі
Зниження швидкості розробки при переході на TS спричинює найпоширенішу помилку — розробники починають писати, зберігаючи стиль JS. Наприклад, створюючи компонент, прописували тип ‘any’. Це як гаджетами Dyson колоти горіхи — у тебе є крутий інструмент, але ти його не використовуєш за призначенням.
Буває, що немає часу повноцінно адаптувати знайдене рішення на JS під усі вимоги TS, тому його швидкома переписують за принципом «щоб працювало». Але важливо це помічати й обовʼязково потім фіксити. Бо якщо таких «вставок» буде багато, неодмінно почнуться локальні пожежі, і ви втратите головні переваги проєкту на TS — стабільність та масштабованість.
Раджу одразу звертати увагу на сувору типізацією, намагатися використовувати й інтерфейси й типи, дженерики й декоратори. Фокус на тому, що ці зусилля — не даремні, і в майбутньому ваш проєкт бути швидким, стабільним та зрозумілим для інших розробників, може допомогти. Їсти на сніданок вівсянку теж не хочеться, але бенефіти обовʼязково прийдуть.
Недоліки TypeScript:
Складність входу. Для розуміння та ефективного використання додаткового синтаксису та функцій може знадобитися час.
Довший час розробки.
Складніші налаштування проєкту TS, може потребувати додаткових інструментів і конфігурацій.
Довгий час компіляції: оскільки TypeScript вимагає етапу перетворення коду у JavaScript, це може ускладнити швидку ітерацію.
Проблеми сумісності при використанні сторонніх бібліотек або фреймворків.
Ускладнений найм.
Чотири міфи про TypeScript
1. TS гарантує надійність коду.
Використання TypeScript є одним із компонентів, який надає йому стійкість, як і покриття юніт-тестами. Жодною із цих складових не варто нехтувати. TS не захищає від помилок архітектури або механічних, корнер-кейсів, того, що розробник щось не врахував, і в результаті застосунок «склався». Він не вирішить усіх проблем, але точно додасть певний відсоток стабільності.
2. У великих проєктах на TS код стає занадто складним, дублюється.
TS — це просто інструмент. Ручкою можна писати охайно та не дуже. Так і тут. Повтори фрагментів коду — це питання стилістики, і неважливо, якою мовою ви пишете. Можна на TS писати дуже поганий код, а на JS — хороший.
Інтерфейси є потужною функцією TypeScript, яка може допомогти зробити код більш придатним для повторного використання та модульним. З їхньою допомогою можна зменшити кількість зайвого коду та полегшити його обслуговування.
3. Аналізатор помилок лише заважає.
При переході на TS редактор IDE може дратувати, збивати та ще більше сповільнювати й так нешвидку розробку. Ніби у вас на смартфоні раптом включили Т9. Але на дистанції це дає перевагу, бо є змога на ранньому етапі врахувати та виправити помилки. Також не забувайте, що можна налаштувати конфігурацію під свій проєкт, наприклад, що редактор вважатиме помилкою, а що ні.
Розробка на TS збільшує етап написання коду, але спрощує інші процеси, наприклад, код-ревʼю, та економить час на виправлення помилок. Не боятися побачити після релізу 'undefined' is not a function — безцінно. Тож ця інвестиція значною мірою окупається.
Отже, довгий час TypeScript сприймався як мейнстрим та використовувався не за призначенням. Але коли розробники справді зрозуміли його цінність та філософію, він почав швидко зростати. На мою думку, на цей час немає технології, яка б могла його затьмарити. З кожним оновленням, розробники намагаються зменшити його недоліки, зробити простішим та швидшим.
Так, нещодавно вийшов TypeScript 5.0. Основні зміни стосуються вдосконалень у структурі коду, алгоритмах та роботи з даними. Оновлення вийшли не глобальними, але є цікаві речі, з якими варто ознайомитися:
Загальне покращення швидкодії коду на 10-20%.
Оптимізація використання памʼяті. Розмір самого пакету суттєво зменшився — на 41% (з 63,8 mb до 37,4 mb) порівняно з TypeScript 4.9.
Декоратори (інструмент, що дозволяє розширити поведінку класів і методів). Якщо попередні версії підтримували експериментальні версії декораторів та вмикалися лише за допомогою флагів experimentalDecorators, то тепер вони вбудовані в TS і можна ознайомитись, як вони працюють. Ймовірно, на цей крок пішли, щоби зберегти сумісність, якщо декоратори стануть частиною стандарту ECMAScript.
ModuleResolution bundler. Щоби оновити застарілі moduleResolution node, node16 і nodenext, які мали проблеми з експортом, були незручними та громіздкими, в TypeScript 5.0 додали сучасний --moduleResolution bundler. Він має гібридну стратегію, чудово ладнає з класичним Node-style та підтримує правила експорту та імпорту.
Підтримка кількох конфігураційних файлів у extends. Ця фіча використовується, коли треба звернутися до певних файлів 'tsconfig.json', що містять ті чи інші налаштування. В останньому оновленні зʼявилася можливість звертатися одразу до кількох файлів.
