Сувора типізація: Typescript, Flow, Javascript  —  бути чи не бути?

Сувора типізація: Typescript, Flow, Javascript  —  бути чи не бути?

  • 1 жовтня, 2023
  • читати 7 хв

Згідно з опитуванням Global Developer Hiring Landscape Survey report 2017, проведеним Stack Overflow, JavaScript є найбільш запитаною мовою програмування серед веб-розробників по всьому світу. З моменту свого створення в 1995 році JavaScript зарекомендувала себе як оптимальний мову роботи з інтерфейсами для браузерів і веб-сторінок. Завдяки багатому набору бібліотек вона також забезпечила нові можливості для візуалізації. Angular [.js], Ember.js і інші подібні фреймворки надали JS необхідну гнучкість і можливості.

Результати опросу

Слід пам'ятати, що JavaScript розроблялась як клієнтська мова для мас, тому її функціональність не така різноманітна, як у інших мов. У ній не вистачає безлічі важливих функцій, необхідних для адекватного написання і підтримки масивних додатків. Щоб впоратися з цією проблемою, веб-розробники створювали такі інструменти, як eslint для сканування коду.

Статистика GitHub за останні три роки також показала переконливе зростання числа проектів, в яких використовується статична типізація JavaScript. Навіть в інших мовах розробники вважають за краще використовувати статичну типізацію замість динамічної.

Статистика GitHub

JavaScript : історія

Mosaic від NCSA був першим загальновизнаним веб-браузером ще в 1993 році. А в 1994 Netscape представила свій популярний запатентований браузер, який отримав назву Netscape Navigator, який вважався єдиним надійним варіантом в 90-х роках. Netscape найняла Брендана Ейха в 1995 році, і в тому ж році їм була заснована JavaScript. За словами Ейха:

«Ми прагнули надати «мову-клей» для веб-дизайнерів і програмістів на неповний робочий день, які будують веб-контент з таких компонентів, як зображення, плагіни і міні-додатки на Java. Ми розглядали Java як «компонентну мову», яка використовується більш дорогими програмістами, де «програмісти-склеювачі» — розробники веб-сторінок — збирали б компоненти і автоматизували їх за допомогою JS».

Припустимо. Ми знаходимося в складному становищі, коли більшість розвинених мов переходять до функціонального програмування та до суворої і статичної типізації.

JavaScript динамічно типізована і дозволяє оголошувати функції, об'єкти і змінні без оголошення типу. Хоча ця можливість і спрощує використання мови, це не завжди зручно. Щоб допомогти впоратися з такими проблемами, і з'являлися TypeScript і Flow.

Мета статті — виділити плюси і мінуси статичної типізації в контексті розробки на Javascript. На додаток до цього ми розглянемо TypeScript і Flow, а також порівняємо їх, щоб в кінці цієї статті ви могли б вирішити: чи варто переносити свої проекти на строгу типізацію замість того, щоб покладатися на «ванільний JavaScript».

Навіщо це потрібно

Згадайте Coffeescript, яка була надзвичайно популярна. Але, хоча я дуже поважаю його винахідника, факт полягає в тому, що у цієї мови були деякі серйозні проблеми (почитайте відповідну гілку листування на ycombinator). Потім з'явився ES6.

Через необхідність підтримувати старі браузери і для інтерактивного виходу функціоналу ES6 у нас стали з'являтися транспайлери, такі як Babel. Coffeescript має багато спільного з ним і теж є транспайлером.

Інструментів CoffeeScript і Babel було недостатньо, що підштовхнуло співтовариство в сторону TypeScript і Flow. Погляньте на тренди (за Flow не ручаюсь, думаю, що виникла контекстуальна помилка, він повинен бути в кілька разів менше).

Статистика Google Trends

TypeScript - це мова програмування з відкритим вихідним кодом, розроблена Microsoft. Вона є суперсетом JS. По інший бік - Flow, який розроблений Facebook.

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

TypeScript чи Flow

Звичайно, і TypeScript, і Flow корисні. Ми, в свою чергу, розгорнемо порівняння з точки зору розробника.

TypeScript

TypeScript, як видно з назви, вміє перевіряти типізацію. Він приймає на вхід (.ts) і генерує (.js) на виході. Існує прапор компілятора nolmplicitAny, який, якщо включений, жадає від вас вказання типів і значеннь, що повертаються для всіх використовуваних аргументів і функцій.

Активація noImplicitAny може мати серйозні наслідки для вашої роботи, особливо при роботі з маловідомими сторонніми модулями. Крім того, я звернув увагу, що при використанні noImplicitAny я став писати частину коду спеціально, щоб зробити задоволеним компілятор TypeScript.

Доступно безліч описів інтерфейсів для бібліотек JS. Якщо говорити про щось популярне, то проблем у вас не буде. Однак, немає впевненості, що розробник, який написав файл .d.ts, зробив це акуратно. Плюс до всього, вам буде потрібно надати визначення типів, якщо ви хочете впровадити сторонню бібліотеку для вашого кодування. Готуйтеся заплатити за сувору типізацію своїм часом.

На додаток до вбудованої демонстрації помилок до компіляції, при використанні TypeScript з IDE на подобі WebStorm перед вами відкриється перехресна навігація і більш точне автозаповнення.

Flow

На відміну від TypeScript, Flow лише сканує ваші .js-файли для виявлення можливих помилок. Іншими словами, він діє як розумний лінтер.

Якщо користуєтеся Flow, то зверніть увагу на пакет для Atom Nuclide.

Усе ж, хто випереджає?

Незалежно від того, хто є вашим фаворитом: TypeScript або Flow, перевірка типів -— це майбутнє JS. Помітною відмінністю між Flow і TypeScript є те, наскільки плавно вони можуть бути інтегровані в поточні проекти. У той час як TypeScript значно складніше, Flow відносно легко впроваджуємо, попереджаючи за ходом базової інтеграції, що перевіряє менше вашого коду, як і очікується. Якщо ви пишете на Angular, то вибір у вас невеликий.

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

Переваги використання статичної типизації

Виявлення помилок на льоту

За допомогою тестування типів легко перевірити працездатність коду ще до його виконання.

Наступні операції дійсні в JavaScript, але ви отримаєте бонус у typescript, наприклад:

static.ts hosted with ❤ by GitHub

Більш точна передача сенсу функції

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

Якщо ви вважаєте, що включення коментарів може зробити те ж саме, ви не помиляєтеся. Але оскільки коментарі є досить докладними, вони порушують загальну структуру коду, зменшують корисну щільність. Коментарі - це наслідок того, що ви не впоралися з передачею сенсу коду в синтаксисі його мови (цікава книга на цю тему: «Чистий код» Роберта Мартіна).

Спрощує налагодження помилок

Нам краще перевірити, що s — рядок, а y — регулярний вираз. Без статичних типів вам знадобиться додатковий код. А без нього нас можуть чекати сюрпризи під час виконання.

Різниця між даними і поведінкою

Оскільки статичні типи чітко розрізняють дані і поведінку, це дозволяє розробникам більш впевнено прогнозувати свої очікування і більш точно пояснювати мету. Це не тільки пом'якшить тиск і двозначність, але також додасть ясності та прозорості під час кодинга.

pressure.ts hosted with ❤ by GitHub

Скорочення ймовірності виникнення помилок під час виконання

Помилки типу під час виконання стають катастрофічними, на чому і живуть такі сервіси як Sentry.

Наприклад, наведений нижче код буде працювати в JavaScript, але відзначатиме помилку компіляції: рядок не існує.

helloworld.js hosted with ❤ by GitHub

Інструмент доменного моделювання (якщо використовувати IDE)

Одна з найкращих особливостей статичних типів. Якщо ви працювали в Visual Studio на мові подібній C #, ви зрозумієте, про що я. Це реально зменшує адміністративну складність. Приклад (у вас реально вийде працювати з субдоменами):

App.subapp.somefunction

Недоліки використання статичних типів

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

Одна з проблем - додаткова вартість навчання інженерів і витрати на супровід типізованого коду.

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

З використанням TypeScript або Flow загальний розмір коду збільшиться на 30% як мінімум. Щільність коду знижується. Це як Ruby або Java :)

Використання статичних типів в JavaScript — Так чи Ні?

Курс Front-End Pro

Рекомендуємо курс по темі