5 незручних фактів про TypeScript

5 незручних фактів про TypeScript
Переклад 8 хв. читання

Я пишу книги про TypeScript, проводжу семінари та тренінги онлайн і офлайн. Кожного разу, коли я зустрічаюся з новою групою розробників, я розповідаю їм деякі факти про TypeScript, з якими їм необхідно ознайомитися:

1. TypeScript не врятує вас від JavaScript

Кожного разу, коли я проводжу воркшопи з TypeScript, є принаймні одна людина, яка вивчає TypeScript, тому що вона спробувала JavaScript, і він їй не підійшов. TypeScript має бути кращим, чи не так? Хибна думка, що TypeScript є "кращою" або "виправленою" версією JavaScript, дуже поширена, вона існує з тих самих часів, коли TypeScript активно просували розробники, які зазвичай працювали з C#/.NET і мали потребу в написанні клієнтських інтерфейсів API. Це також був мій перший контакт з TypeScript: Хтось сказав мені, що знайшов "кращу версію". І це також було причиною, чому я спочатку відкинув TypeScript.

Але дозвольте мені сказати вам, що TypeScript, без сумніву, є надмножиною JavaScript, а це означає, що він увібрав у себе всю історію, примхи та недоліки JavaScript. Так, це допомагає вам уникати помилок, і це допомагає вам працювати з динамічно типізованою мовою програмування. Він видає помилки, коли щось не сходиться. Але у своїй основі це все ще JavaScript. Якщо ви достатньо довго працюєте з TypeScript, то побачите, як жовті плями просвічують крізь синє покриття статичних типів.

Система типів TypeScript повністю охоплює структурну типізацію (і не дарма), і це, в поєднанні з тим, що типи є лише метаінформацією, яка лежить поверх наявного коду, може відштовхнути багатьох людей, які очікують швидкого переходу з однієї мови на іншу.

Якщо ви хочете вивчити TypeScript, не думайте, що зможете залишити JavaScript позаду. Він дістане вас і там.

2. TypeScript додає складності

TypeScript відомий своїм поступовим підходом: Використовуйте стільки типів, скільки хочете, заглиблюйтесь настільки, наскільки хочете. TypeScript також прагне постійно знижувати бар'єр для початківців, переконуючись, що люди, які знають про небезпеку JavaScript, можуть отримати користь від інформації про типи. Кожного разу, коли ви пишете JavaScript, наприклад, у Visual Studio Code, TypeScript працює за лаштунками і надає вам інформацію про вбудовані API тощо. Дуже тонко, а іноді й непомітно. Насправді багато людей думають, що вони можуть жити без TypeScript, тому що підтримка JavaScript в сучасних редакторах така фантастична. А знаєте що, це завжди був TypeScript!

Проте, TypeScript додає рівень складності до вашого проєкту, про який ви повинні знати. І я говорю не тільки про типи та складні, просунуті функції, такі як умовна типізація. Я говорю про всі регулятори, перемикачі та інтеграції, які дає TypeScript, щоб бути сумісним з усім, що тільки можна! Запускаєте TypeScript у Deno? Так. У Node? Звісно! Internet Explorer 5? Попався. З Бабелем? Звісно! Babel і Webpack? Так. Esbuild? Все, що завгодно! З моєю бібліотекою схем семирічної давності? Вимкніть noImplicitAny, і все запрацює! Поєднання UMD, AMD та CommonJS? Ха, звичайно! JSX? Ага. TSX? Все чисто! TSX в Реакті 18? Угу! 17? Так!

Ну, ви зрозуміли, що я маю на увазі. Компілятор TypeScript налаштовується за допомогою TSConfig, величезного JSON-файлу з безліччю можливостей для адаптації TypeScript до ваших потреб. Існує так багато різних варіантів конфігурації, що стає дуже важко визначити, які правила зараз насправді застосовуються. І як тільки ви подолаєте цю феєрію конфігурації, ви можете почати вивчати всі компроміси, які TypeScript робить для вас, щоб ви отримували безпечний код.

TypeScript - це складне питання.

3. TypeScript не є типобезпечною мовою

Для багатьох це може бути несподіванкою, але TypeScript насправді не є типобезпечним. Перевірка типів у TypeScript дуже добре працює у тому, що я люблю називати "внутрішнім світом типів" вашої програми. Це та частина, де ви визначили свої типи, операції над ними та їхній потік у вашій програмі. Тут все, що повинно працювати разом, буде працювати разом, а все, що ні, буде викликати червоні хвилясті лінії та помилки компілятора.

Але є крайні випадки. Якщо ви покинете внутрішній світ безпечних типів і вам потрібно буде дотягнутися до практично будь-якого вводу-виводу. Введення даних користувачем, доступ до файлів, отримання даних через інтернет. Тут TypeScript не має жодного уявлення про типи та повинен покладатися на те, що ви йому скажете. Вам потрібно створювати анотації типів, твердження типів або величезні перевірки потоку управління, щоб дати TypeScript підказку про те, чого очікувати. У TypeScript ви можете будь-коли змінити тип на інший у будь-який момент. Ви можете перевизначити широкий тип, який допускає багато значень, але менш специфічний, на вузький тип, який допускає менше значень, але надає більше інформації в будь-який час, іноді навіть не помічаючи цього. І бувають ситуації, особливо з API, які повертають будь-яке значення, коли ви можете анотувати щось зовсім інше, ніж те, що ви отримуєте назад.

І ніщо нас від цього не врятує.

Мало того, у TypeScript є кілька випадків, коли безпека типів може бути принесена в жертву продуктивності. І це ті сценарії, які можуть дійсно вас розчарувати!

Найцікавіше те, що TypeScript ніколи не ставив собі за мету бути доказово безпечним для типів. Вся увага приділяється підвищенню продуктивності розробників. Вона не повинна заважати, а лише допомагати швидко знаходити потрібну інформацію. Ще один компроміс.

4. TypeScript має багато різновидів

На якому TypeScript ви пишете? JavaScript з вкрапленням типів? Йдете ва-банк з ієрархіями класів і використовуєте всі розширення мови, як у 2012 році? Пишете переважно на React і потребуєте розширення TSX? Пишете функціональний код і багато працюєте з умовними типами та варіативними типами кортежів? Або ви використовуєте експериментальні декоратори, які надають інформацію для газильйонів інших компіляторів, які запускаються після цього? Що працює найкраще для вас? І особливо для вас і вашої команди?

У TypeScript так багато можливостей, що я не бачив жодного проєкту, який був би схожий на інший. Кожна команда придумує щось своє і використовує різноманітні інструменти для самовираження у TypeScript. І всі вони мають свої особливості та компроміси. Перерахування (Enums) можуть мати гарний API, але вони є номінальними в системі структурних типів і створюють код, який не піддається деревоподібному кодуванню. Абстрактні класи допомагають вам визначати спільну поведінку, але не мають жодного коріння в JavaScript. Умовні типи майже завжди вимагають додаткової документації, щоб люди могли зрозуміти, що було зроблено через деякий час.

Ви вже вирішили, що використовувати - типи чи інтерфейси? Константні перерахування (const enums) чи звичайні перерахування? Ви робите висновок чи коментуєте? Вам все одно? Як ви ставитеся до TypeScript?

Це майже як у C++, де командам завжди потрібно визначитися з підмножиною мови для управління складністю. TypeScript просить вас про те ж саме.

5. Воно того варте

Я займаюся TypeScript вже 6 років і написав дві книги на цю тему. Я проводжу воркшопи для команд і публічно для таких організацій, як Smashing Magazine. Сьогодні я показав вам багато прикладів того, що TypeScript - це не тільки блиск і слава.

І все ж таки. TypeScript того вартий. Зрозумійте мову, усвідомте її компроміси та застереження, а також те, що вона дає вам. Тоді ви зможете повністю прийняти силу TypeScript як системи типів і мови програмування.

І знаєте що, потім це починає приносити задоволення!

TypeScript створений для того, щоб полегшити ваше життя і життя вашої команди. І це йому вдається! Спробуйте повернутися до проєкту через 6 місяців і спробувати відтворити ментальну модель, яку ви мали з вашої програми. Або подивіться на добре продумані шрифти, які розповідають вам історію. Я завжди обираю TypeScript.

Джерело: 5 Inconvenient Truths about TypeScript
Помітили помилку? Повідомте автору, для цього достатньо виділити текст з помилкою та натиснути Ctrl+Enter
Коментарі (0)

    Ще немає коментарів

Щоб залишити коментар необхідно авторизуватися.

Вхід / Реєстрація