Як я полюбив TypeScript
Колись я робив пост, в якому розповідав про те, чому ми мало використовували TypeScript в WebbyLab. Всі ті аргументи були дійсні на той час і для тієї ситуації. Ось пост — https://t.me/jabascript/19.
Але якщо коротко, то
✴️ Порівнювати треба не TS vs JS, а TS + тести + процеси + тулінг проти JS + тести + процеси + тулінг. І якщо вибирати, що писати — тести чи типи, то ті 20% часу, які були використані на TypeScript, краще витратити на написання тестів. І якщо у вас вже є 80% покриття тестами й багато статичного аналізу (а ми залучали все, що могли для eslint, і використовували багато плагінів, навіть власні), то додавання TypeScript дає лише кілька відсотків в детекції багів, а вартість розробки збільшується значно. Хоча, звісно, завжди були певні проекти, які точно виграли б від використання TS (той самий Excel на JS, про який я робив доповіді).
✴️ Також на той час TypeScript був значно обмеженіший, і багато речей з JavaScript не можна було написати нормально в TS (хоча й зараз є нюанси).
✴️ Навчити джуна повноцінно TS було дорого й довго (6 місяців, а не 1-2 місяці, як з JS). Окрім обов'язкових тестів на бекенді, на фронті в нас усюди були обов'язкові PropTypes, що додавало рантайм перевірок. І якщо ти запускаєш свій код, то одразу бачиш проблеми.
Я сам не раз "залипав" на описах типів на години, а часом можна було й пару днів витратити, якщо це частина якогось фреймворку.
✳️ Що змінилося сьогодні?
ШІ зробив впровадження TypeScript значно дешевшим. Незрозуміла помилка в коді — спитав LLM, не знаєш, як краще описати інтерфейс — спитав LLM, не знаєш, як переписати складний клас з JS на TS — спитав LLM. Це як кожному джуну (і не тільки) дати експерта з TS, і він буде і допомагати вчитися, і підказувати, як написати, і допомагати дебажити, знати про більшість особливих фіч TS, і багато іншого.
Я не джун і пишу на TS вже багато років, але навіть мені LLM сильно спрощує роботу з описом типів. Правда, я помітив, що тепер лінь писати тести, треба також залучати LLM 🙈. TS це ніяк не заміна тестам, але код на TS без тестів все ж таки стабільніший за код на JS без тестів.
Сьогодні TS має бути, як вибір по замочуванню для JS проектів, так само як і вміння ефективно користуватися LLM. І якщо ви думаєте, що всі інженери у вашій компанії вміють ефективно користуватися LLM, то ви помиляєтесь.
Що думаєте з цього приводу?
Колись я робив пост, в якому розповідав про те, чому ми мало використовували TypeScript в WebbyLab. Всі ті аргументи були дійсні на той час і для тієї ситуації. Ось пост — https://t.me/jabascript/19.
Але якщо коротко, то
✴️ Порівнювати треба не TS vs JS, а TS + тести + процеси + тулінг проти JS + тести + процеси + тулінг. І якщо вибирати, що писати — тести чи типи, то ті 20% часу, які були використані на TypeScript, краще витратити на написання тестів. І якщо у вас вже є 80% покриття тестами й багато статичного аналізу (а ми залучали все, що могли для eslint, і використовували багато плагінів, навіть власні), то додавання TypeScript дає лише кілька відсотків в детекції багів, а вартість розробки збільшується значно. Хоча, звісно, завжди були певні проекти, які точно виграли б від використання TS (той самий Excel на JS, про який я робив доповіді).
✴️ Також на той час TypeScript був значно обмеженіший, і багато речей з JavaScript не можна було написати нормально в TS (хоча й зараз є нюанси).
✴️ Навчити джуна повноцінно TS було дорого й довго (6 місяців, а не 1-2 місяці, як з JS). Окрім обов'язкових тестів на бекенді, на фронті в нас усюди були обов'язкові PropTypes, що додавало рантайм перевірок. І якщо ти запускаєш свій код, то одразу бачиш проблеми.
Я сам не раз "залипав" на описах типів на години, а часом можна було й пару днів витратити, якщо це частина якогось фреймворку.
✳️ Що змінилося сьогодні?
ШІ зробив впровадження TypeScript значно дешевшим. Незрозуміла помилка в коді — спитав LLM, не знаєш, як краще описати інтерфейс — спитав LLM, не знаєш, як переписати складний клас з JS на TS — спитав LLM. Це як кожному джуну (і не тільки) дати експерта з TS, і він буде і допомагати вчитися, і підказувати, як написати, і допомагати дебажити, знати про більшість особливих фіч TS, і багато іншого.
Я не джун і пишу на TS вже багато років, але навіть мені LLM сильно спрощує роботу з описом типів. Правда, я помітив, що тепер лінь писати тести, треба також залучати LLM 🙈. TS це ніяк не заміна тестам, але код на TS без тестів все ж таки стабільніший за код на JS без тестів.
Сьогодні TS має бути, як вибір по замочуванню для JS проектів, так само як і вміння ефективно користуватися LLM. І якщо ви думаєте, що всі інженери у вашій компанії вміють ефективно користуватися LLM, то ви помиляєтесь.
Що думаєте з цього приводу?
