Я просто категорично радий бачити всіх вас. Дуже сумував за офлайн-конференціями, то через ковід, то через повномасштабне вторгнення. Так що дуже приємно, по-перше, бачити вас тут, і по-друге, що до цього часу немає тривог. Сподіваюся, що мого щастя вистачить, щоб його не руйнувати. Хто не знає, мене звати Ілля Климов, я працюю в GitLab п'ять років, а 18 років пишу на JavaScript. Жартую, що мій досвід вже можна наливати в барі окремо. Також, по-перше, хочу сказати, що ви всі неймовірні. Є навіть Google Developer Expert, які мене дуже просять розповідати на конференціях, але я не люблю бути на них.

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

Оскільки я очікував, що їх буде не багато, оскільки у FrontEnd все занадто швидко змінюється, давайте розглянемо коротке підсумкове повідомлення цієї презентації. React — це добре, TypeScript — фігня. Rescript. Це, власне, куди я відійшов у своїх проєктах. Це моє серце. Якщо ви думаєте, що щось змінилося, ви або мене дуже добре знаєте, що пан Ілля любить перевзуватися під час роботи, або, можливо, вам просто не вистачає інформації. JavaScript — це найнормальніша мова програмування. Не TypeScript. І я так і приходжу, говорю: "Ми любимо чисті функції. Чисті функції — це добре." Приходить React, а ось ці хуки виглядають як чисті функції, але працюють не так. Вони, фактично, зберігають стан всередині себе, тому, ви розумієте, це теорія та практика, моє. Добре.

Потім був UGS, третій. Вже вийшов. Але, чесно кажучи, UGS 3.0 виглядав так, наче його примушують випустити або він просто втомився і вирішив випустити UGS 3. Тому UGS 3.0 виглядав так, наче навіть йому не вірили, але це, звісно, не правда. Але це виглядало так, що Evan, можливо, був змушений випустити його, чи може він просто втомився і вирішив випустити UGS 3. Так от UGS 3.0 виглядав так, що ось вам бібліотека, але як її мігрувати? Да біс його зна. Жодної готовності інфраструктури. Жодної готовності екосистеми. ViewCompat, інструмент для міграції, з'явиться тільки у версії 3.2, якщо я не помиляюся. Але навіть він не допоможе, але це не всі тонкощі. От і Angular виглядає окремо.

Усі ці картинки, які ви бачите, я генерував за допомогою DALLA, використовуючи GPT-4. І коли я попросив створити мені картину кривавого Enterprise, спочатку він відмовився, сказавши, що не може генерувати. Потім я сказав: "Будь ласка, згенеруй мені кривавий Enterprise в метафоричному плані, без насильства." І от воно створило мені цю картину. І вона мені дуже подобається, оскільки несподівано добре описує, як я тоді відчував Angular. Це щось потужне, красиве, як корабель, але занадто ускладнене, нерозбірливе. По-перше, нащо корабель покритий? По-друге, як? І по-третє, як це має працювати? І як вишенка на торті? Ви знаєте, що ChatGPT та, взагалі, ці нейронні мережі дуже погано працюють з текстами, тому ChatGPT намагалося написати слово "Enterprise" зверху, але не вдалося. No pun intended. Так що "Enterprise" — це гарний допис до того, як я відчував Angular.

Мені здавалося, що вони жили в своєму власному світі, як у нас єдинороги, оскільки у них все своє. У нас є свій Dependency Injection, свої Angular-модулі, свої підставки та все інше, що вам треба. Але ще однією ключовою особливістю тих часів була індустрія. З точки зору розробки вона виглядала приблизно так. Якщо ви не знайомі із терміном "вертольотні гроші", це для стимулювання економіки. Під час ковіду друкували гроші, вкидали їх в економіку, і тому в нас взагалі екосистема IT просто купалася в халявних грошах. У нас було багато відкритих вакансій, стартували стартапи, ті, хто слідкує за біржею, пам'ятають, як дорого коштував Zoom на біржі. Сподіваюся, ви встигли його продати, не так, як я. І так далі. Здавалося, що ця музика буде вічною. Перейдемо до 2023 року. Що змінилося? Як я кажу, Rescript я все ще люблю, про що я не розповідав. Чому? Тому що Rescript, на відміну від TypeScript, був і залишається Sound Time System. Цьому терміну немає гарного перекладу на українську мову, тому він означає надійну систему типів. Тобто, на відміну від TypeScript, який ставить перед собою завдання створити вам систему типів, яка є надійною і описує деталі, Rescript гарантує це і відкриває такі можливості, які мені дуже подобаються. Єдиний слайд з рекламою TypeScript — це те, що тут відбувається. Я просто запускаю якийсь скрипт, який називається "Remove Unused Field" з пакету Rescript Relikely.

Він аналізує весь мій проєкт і прибирає з моїх GraphQL запитів поля, які не використовуються в моєму коді. По всьому проєкту, без будь-яких аналізів. Чому? Тому що на відміну від TypeScript, де те, як я кажу на співбесідах, реверанс до пана Сергія Бабіча, той самий Душніла, який запитує, і я відповідаю: "А як у TypeScript?". Людина відповідає: "Я знаю, що я знаю TypeScript. Але як у TypeScript? Як у TypeScript?". І от відповідь — ніяк. Це неможливо виразити в TypeScript. Це можна було у Flow, плак-плак. Тож, чому у мене таке більш спокійне ставлення стало до TypeScript? Чому я вже не говорю, що він поганий? Не тому, що в мене в житті з'явилися інші проблеми, а тому, що з моєї точки зору TypeScript за ці два роки поступово пройшов з точки зору… не видно. Добре. Пік оф експеримент. Пік оф експеримент. Пік невиправданих очікувань. Ну, ми десь зараз, я не знаю, мені здається, що ми почали на спад, а деякі кажуть, що ми вже досягли просвітлення. Це неоднозначне питання, про що йдеться. Ну, ви вже бачили, якщо ви слідкуєте за новинами або на моєму україномовному каналі дивитися балачки. В мене немає QR-кодів на підписку на мій YouTube канал в презентації.

Так от, ви чули чи знаєте оці новини? Свелт відмовляється від TypeScript, Дено викинув TypeScript зі свого коду і так далі. Насправді це не так, там, як завжди, є певні нюанси, але як кликбейт звучить відмінно. От, це вже означає, що люди починають усвідомлювати обмеження TypeScript і з'являються інструменти, яких не було два роки тому, або були в такому зачаточному стані. Які допомагають нам бути більш продуктивними, і я можу покладатися на ці інструменти.

Фактично, у нас в TypeScriptі десь останній... Господи, у нас в TypeScriptі? У вас в TypeScriptі? Так, в TypeScriptі почалася ера кодогенерації, і це дуже добре. Два роки тому я розповідав і казав, що мені, наприклад, дуже до вподоби концепція Dart. Де Dart каже, що в нас дуже багато зав'язано на кодогенерацію. З GraphQL ми вміємо вже генерувати правильні TypeScript-типи. З OpenAPI, з Swagger, Prisma, якщо ви її використовуєте, перестаньте. Drizzle, TRPC, господи, чого там тільки немає. Навіть, якщо ми візьмемо Next та Nuxt екосистеми, де є автоімпорти. Я не знаю, чому вони всім подобаються, але вони є, вони теж використовують кодогенерацію, щоб у вас була коректна система перевірки типів щодо автоімпортованих компонентів. І це добре. Тобто, фактично, ми приходимо до того, що TypeScript з "One thing to rule them all" приходить до того, що це лише одна складова інструментів.

І головне, чому я більше поважаю кодогенерацію, тому що я не дуже великий фанат Convention over Configuration. Точніше, не так. Convention over Configuration не є абсолютно поганим. Але коли в нас є магія, завдяки конвенції, яка виконує якусь логіку, то я дуже нещасний, тому що де бажати цю магію, як Senior розробнику, зазвичай мені. Чому мені більше подобається кодогенерація? Тому що кодогенерація – це, зазвичай, засіб надійно та ефективно згенерувати boilerplate код, який буде простий та зрозумілий для сприйняття. Тобто ми отримуємо краще з двох світів. З одного боку, цей код зрозумілий щодо відладки, не містить магії, як воно працює. А з іншого боку, цей код пишу не я. Нічого мене не забавляє більше, ніж код, який пишу не я. Ще одна річ, яка дуже стала допомагати не досвідченим розробникам в TypeScript, це ChatGPТ, який доволі непогано пише посередній TypeScript код. І навіть, звичайно, це не тільки ChatGPT Copilot, інші системи штучного інтелекту.

Наприклад, мені дуже подобається майкрософтівський проект TypeChat, який допомагає людям за допомогою TypeScript і використовуючи GPT-4 будувати інтерфейси для спілкування з вами, вашою програмою, з людиною на людській мові. Для тих, хто не знає, дуже коротко такий selling message, ні, elevator pitch, реклама в ліфті. Ви просто кажете, що в результаті цього запиту, в результаті аналізу цього тексту, що дає вам людина, ти маєш мені запитати, заповнити отакий TypeScript тип. Наприклад, якщо ми, перепрошую, вже бачите, не було багато практики, сідає горло. Так от, якщо ми робимо черговий to-do-list, то ми кажемо, в результаті аналізу запиту рядка, що користувач вів, будь ласка, заповни мені дату початку завдання, що має бути типом дати, текст завдання, пріоритет, який має бути, я думаю, з таких типів, і далі трапляється магія. Якийсь ще хейтив. Тобто система робить запит до вашого endpoint в OpenAI, аналізує відповідь, якщо відповідь з точки зору TypeScript типів не коректна, воно підлаштовує prompt автоматично, автомагічно, який знову йде на запит до chgpt, і ви отримуєте гарантовано типізовану відповідь від користувача. Хіба це не диво, коли ми нарешті можемо примусити цю ненависну прокладку між монітором та клавіатурою писати правильні типізовані запити до нашої системи.

Фактично, завдяки подібним підходам, ми позбавляємось оцього запиту. Але цього фактору не визначено, коли ця, як там наш один колега сьогодні казав, я хочу прибрати всіх програмістів, в нас пишуть мавпи, коли оця мавпа пише запити в типізованій системі. Фактично TypeScript перетворюється на щось, що є таке. В GitLab ми використовуємо термін most boring solution. Тобто щось таке типове, сказав Ілля, тим часом GitLab навіть не планує переходити на TypeScript. Добре. А що ж щодо React? Трішки інтерактиву. Боже, як я за ним сумував. До речі, ті, хто дивиться в онлайні, я долучився до Discord. Якщо у вас є питання і в нас буде трішки часу, а в нас він можливо буде, тому що останнє доповідь, то можете ставити питання в Discord чатику, я одразу погляну їх наприкінці, відповім. Можливо.

Так от, React. Що нового з'явилось в React за останні два роки? Серверні компоненти. Серверні компоненти, ще. Shadow DOM, ну, так, правда, до веб-компонентів справді система. Ще? Suspense. Suspense, так, ну там Suspense, Suspense List, та ще до біса цих. Ще? Нові хуки. Нові хуки, ну які, ну просто. Use ID. Use ID, ну добре. Там насправді з'явилося, якщо особливо ви слідкуєте за розвитком, React, що є ще не в релізі, там і Use Optimistic Response, який пов'язаний з контекстами. Ще щось, дуже-дуже багато всього. Але в той же час екосистема React рухається в напрямку, який нічого в мене, окрім здивування, не викликає. Чому так? І це навіть не про те, що вони раптом вирішили у мастері React патчити фетч. Ну тобто ви підключаєте React, а він вам Windows Fetch пропатчив. Сюрприз. Ні, то таке. На фоні іншого, насправді, якщо ви не знали, то у 17 React, у 18 перестали, React патчив вам консоль лог тихесенько. Нащо? Тому що у Dev режимі, коли ви в Strict моді, то ви всі знаєте, що хуки викликаються двічі. Так, щоб ви не бачили двічі консоль лог, воно патчило консоль лог. Це в 17 React, у 18, дякувати Богові, прибрало. Так от, перш за все міграція на серверні компоненти. Хто мав, підніміть, будь ласка, руки і потримайте, хто мав вже нагоду поратися, повикористовувати серверні компоненти. Ну не так вже й багато добре. А тепер опустіть руки ті, залиште тримати руки ті, хто до того прочитав документацію про них на сайті React. Один. От я вас трішки підловив. Немає документації серверних компонентів на сайті React.

Тобто от фіча є, і фіча вже у продакшені, і вони вважають її стейбл, а документації немає. Немає. Де той React, який я міг раніше розповісти за дві години? Серйозно, тому що це ще за часів клас компонентів. Зараз трішки більше треба, щоб про хуки розповісти і зламати людям мозок. Але все одно, що це компонент, він ось так працює. Тепер в нас є серверні компоненти, які команда React, ми до цього ще повернемось, вважає майбутнім, але документація у них є на сайті Next.js. І от найбільше що... Що мені непокоїть наразі в екосистемі React, це Verzele. Verzele це, власне, люди, які одна, мабуть, з двох найбільших компаній, яка тримає нашу фронтендерівську екосистему. Перша Verzele, друга Netlify. З найбільших. Verzele належить, ой, що там тільки до нього не належить, ну, мабуть, найбільший, це Next.js Svelte. І ви знаєте, Verzele це VC-funded company, тобто їй дали гроші, гроші вона має повертати. І в мене, знаєте, такі флешбеки, які, якщо вам не зрозуміло, що є товар, то, скоріш за все, товаром є ви.

І от, фактично, поведінка команди Verzele, яка драйвить наразі розвиток React, дуже багато людей які з React перейшло і працюють, власне, на Verzele, призводить до того, хочеш бути наймоднішим хлопцем в місті або в селі, хочеш використовувати серверні компоненти, ласкаво просимо до Next.js. В нас навіть документація до нього є. А команда React якось потім доробиться. І ще одне. Спочатком повномасштабного вторгнення я почав розуміти, що час це найважливіше в моєму житті. І знаєте, як-то раніше жартували, що життя занадто коротке, щоб безпечно витягати флешку. Так от зараз я хочу перефразувати це, що життя занадто коротке, щоб писати залежності у usability.

Чому 2023 року, коли в нас далі генерують такі красиві картинки, коли в нас є Copilot, ChatGPT тощо, ми не можемо проаналізувати залежності, які використовуються в usability, і автоматично їх написати. Коли в нас є Svelte з Compile Time Reactivity, коли в нас є Vue, якого там власна модель реактивності, коли є Solid, який дуже схожий на React. А чому? Та забудьте. Хто не знає, знову ж таки, хто ж дивиться ці доповіді 2021 року? Ще 2021 року на ReactCon 2021 розказували, що нас чекає різдвяне диво. React4get мав бути або має бути компайлером, який аналізує ваш реактивний код та коректно проставляє мемоїзації, залежності ваших ефектів тощо, щоб ви цього не робили самі. Бо це, ми ж розуміємо, що залежності usability не дуже багато цінності містять. Навіть якщо ви хочете бути найрозумнішим і сказати, а я хочу, щоб до цієї залежності, коли ця залежність змінюється, хоча вона використовується, в ефекті він не перерендувався, то в нормальній команді прийде ESLint і скаже, агов.

Добре. Але проблема React те, що скільки вже? Майже два роки? Ну, може, у нас буде різдвяне диво 2023, але я чомусь скептичен, що випустять цей компайлер тощо, тому що це реально був би і це має бути важливим кроком вперед, реактивської екосистеми, то проблема в іншому. Ми живемо в світі фронтенду, де, як казав пан Льюіс Керрол, для того, щоб залишатися на місці, треба бігти, а щоб розвиватися, треба бігти вдвічі швидше. React біжить, він розвивається, проблема в тому, що інші біжуть вдвічі швидше. І зараз ми про це поговоримо. Єдине, що я хочу сказати, що мені дуже подобається і не подобається одночасно дискусії в React. Якщо ви не знали, React зараз розповідають про те, щоб зробити техформ фактично реактивським компонентом, який буде мати специфічну поведінку. Тобто ви зможете писати форм action дорівнює хендлер і писати хендлери форм, не ловити подію submit, а, власне, от обробляти як екшени. І при чому зараз там дуже велика дискусія, а от такі форми, вони мають робити пост на сервер за замовчуванням чи get?

Діло в тому, що html 20 скільки той йому років, він вже старий, дуже старий, за замовчуванням сабмітить форми get. Але сабмітити форми get не є безпечним. І от фактично в нас, знаєте, такий вибір. Є два стільці. Один – інформаційна безпека щодо того, який… Щодо пост – це безпечно, це надійно, тому що у get є в середньому, давайте, більше двох кіло байт, краще в get запиті не відсилати, або вас чекають несподіванки з певними корпоративними проксями на японській залізниці. А з іншого – ну камон. Типу, коли у вас є техформ, який виглядає як техформ, крякає як техформ, але робить за замовчуванням пост. Це знову ж таки підвищення складності, і це створення специфічної до екосистеми речі.

Що ж там у Vue, наприклад? Vue розвивається. Vue 3.3, нарешті. По-перше, найвизначніша річ, яка… з'явилася у Vue – це VIT, який виріс обіч екосистеми Vue. І, чесно кажучи, настільки виріс спойлер, що Evan Vusk скоро перестануть мейнтейнити Vue і піде до VIT тільки. Цієї інформації немає публічно. Тому VIT… Причому дивіться, кожен намагається побудувати свій бандлер. Команда Next2, якщо хтось дивився NextConf, як вони пафосно презентували турбопак. Якщо ви пишете на Next і пробували включити турбопак, то от, от, бачите ці смішки істеричні? Очікування – реальність. Тобто те, де вам продавали 100x пришвидшення, насправді, іноді це було, окрім проблем з налаштуванням, навіть сповільнення відносно якого-небудь Vito. Тобто Vue ж на яка система розвилася… І от мені подобається… Я прямо наведу три великих приклади щодо Vue-шної екосистеми, що Vue-шна екосистема розвивається не так, як Verzele, який намагається замкнути все на себе. Вона генерує окремі проєкти, які виростають за межі Vue. Перший – це VIT. Другий, як ви думаєте, може хтось знає, що це за лого? Воно дуже свіже. Воно може бути знайомим тим, хто пише на Vue. Це Volar. Volar – це система перевірки типів у Vue. Два роки тому мій був головний казус або головна претензія до Vue. Тому що я пишу код на TypeScript, наприклад, у скрипті, а потім я пишу шаблон, де я можу творити все, що завгодно. Тепер у Vue-шній екосистемі завдяк Volar забезпечена повна… …повна типізація шаблонів, повна включаюча слоти, включаюча події, все. За допомогою TypeScript.

Але Volar тепер, вони нещодавно, навіть це не анонсували публічно, але сайт вже можна знайти в Інтернеті. Вони говорять, що ми більше не просто розширення VS Code для перевірки Vue. Ні. Ми інструмент для побудови системи статичних видів. Для цих перевірок інших мов програмування, переважно композитних. Композитні - коли маємо кілька елементів. Наприклад, у Vue - це, скажімо, скрипт і шаблон. Svelte - це також скрипт і шаблон і так далі. Тобто вони також виходять за межі системи Vue.

І тут з Volar відбулося одне дуже круте подія, яка сталася, як кажуть, JetBrains, які зазвичай героїчно пишуть свої власні системи контролю типів і так далі, щоб бути найкращими, де підтримка Vue була десь поза межами, вони відмовилися і тепер використовують Volar у себе. Добре. І третє і останнє - це екосистема NGS. Якщо ви не знаєте, що це таке - це набір малих утиліт у дуже унікальному стилі, які роблять все. Наприклад, це система плагінів для систем збірки, яка не залежить від самої системи збірки. Хочете, додаєте до Rollup, Vite, Webpack і так далі - неважливо. Наприклад, це малий, дуже швидкий веб-сервер H3. Це дуже велика екосистема, яка активно розвивається у Nuxt 3. Панель вперед, знаю, що доповідь, звичайно, 40 хвилин. Дивлюся на таймер, думаю, що у мене є час, а насправді залишилося всього 40 секунд. Так що я пришвидшуємося.

І третє. А що там у Angular, який, як я сказав, такий кривавий для підприємств? Я не знаю, що сталося. Так що я знаю, я думаю, що, наприклад, це значний вплив пані Сари Драснер, яка прийшла до Google. І, насправді, я знаю трошки більше, оскільки веб-експерт, у нас є конфіденційна інформація. Але Angular, ви не повірите, повертається до коренів, з яких він виходив усе це час від Angular 2. По-перше, швидкодія. Ось як змінювалася швидкодія найпопулярніших фреймворків, порівняючи з... Внизу це версії Chrome. Це не просто хтось випадковий перевірив це, це за результатами тестів... Господи, як його називає? Кенгу-тест чи... Я не пам'ятаю, правильний тест реактивності, який всі ви бачили у вигляді таблиць. Той, де швидкість обробки React. Ось ці таблиці візуалізовані за версіями Chrome, як вони змінюються. Уявіть, вже давно React повільніший за Angular. Але він ще прискориться з виходом Angular 17. Ні, мені не платять за це. Vue у версії 3.4 ще більше прискориться завдяки новій оптимізації реактивності. А щодо React? Забудьте. Коли-небудь вийде. Наскільки він вплине? Подивимося.

Якщо раніше ваш компонент на Angular виглядав так, дивіться, ng-модуль, наша система модулів, технічний компонент і так далі, то тепер він виглядає ось так. Тепер ми можемо не використовувати ng-модулі. Ви можете, якщо вам потрібно, але якщо вам просто потрібен окремий компонент, о, standalone true, і все, поїхали. Виглядає набагато більш зрозуміло для людини, яка не знайома з Angular. Компоненти виглядають, як компоненти. Фанати класичного React трошки сумують, оскільки це дуже нагадує їм. Експорт-клас, і все.

Команда Angular, на відміну від інших, вже тоді знала, що дуже погана ідея зав'язуватися на декоратори, які були експериментальні у TypeScript. І тепер у нас заїхали декоратори, і тепер вони інші. Не можна просто так перевірити. Треба писати старі експериментальні декоратори на нові. Але команду Angular це не покоїть. Вони ще два роки тому написали власний компайлер, який насправді ці декоратори до TypeScript не дотягує. Тобто це їх власний синтаксис, ім не потрібно це реімплементувати.

Отак виглядало дерево раніше в 14-й версії. Спеціально, бачите, не влізло. Це дефолтно. Тепер воно виглядає ось так. Набагато менше якихось дивних там environmentів, тощо. Набагато менше модулів. Роутінг тепер теж можна. І головне. Last but not least. В React, в Angular одумалися і сказали, Rx же це не для людей. Коли мене запитували, для того, щоб зрозуміти RxJS, потрібно, щоб ти дивився на світло. І бачив не світло як хвилю, а як потік фотонів. От. Вони нарешті зрозуміли. Це не означає, що Rx поганий. Rx крута екосистема, яка дозволяє ефективно описувати круті речі. Виразно. Ефективно. Але для цього потрібно зламати повністю ваше світосприйняття і писати у RxStyle. Але здебільшого пересічному розробнику це не потрібно.

І вони такі. В нас тепер будуть сигнали. В нас тепер три головні примітиви Angular. Це сигнал, комп'ютед та ефект. View такий. Так, а ви знаєте, комп'ютед, watch-ефект. Ефект у View називається watch-ефект. Я десь це чув. Та ми якось теж завезли сигнали в себе. Solid. Solid весь побудований на сигналах. Svelte. Хто дивиться? П'ятий Svelte. Руни. Річ Харріс вийшов. Ми знову перевинайшли реактивність. Хто не знає, це ж була легендарна доповідь Річа Харріса, творця Svelte 3. Перевинайшов реактивність. Ми знову перевинайшли реактивність. В нас тепер є під капотом сигнали. В нас є ефекти. В нас є комп'ютеди. І навіть лід. Дивно, але Google його ще не закопав. Десь нещодавно був реліз третьої версії. Каже. Ви знаєте? А ми вважаємо сигнали гарною моделью реактивності. І ми... Це знову ж таки дивно, що Google... Так. Мене виженуть точно. Що Google зі своєю любов'ю до Not invented here не став переписати свою реалізацію сигналів. Вони сказали. Ми візьмемо реалізацію Preact просто тому, що вона норм. А взагалі, поки воно не стандартизовано, ми вам зробимо адаптери до найпоширеніших систем сигналів. Тому що зараз... З цією реактивністю у нашій фронт-енд екосистемі є одна велика проблема.

Коли у вас в проєкті використовуються дві чи більше систем реактивності, вони не взаємодіють між собою. Тому що немає стандарту. Ми такі у Гітлайбі. Ми використовуємо Vue. Де в нас взяти другу систему реактивності? А в нас є Vue, в якого є своя система реактивності. І є Apollo, який всередині себе тягне обзор ваблі та свою систему реактивності. І вони... Ти такий. А що виконається першим? Оновлення компоненту чи система реактивності всередині Apollo? Особливо, коли тести пишеш. Так от. На відміну від обзор ваблів, які назавжди застрягли на Stage 1, сигнали, я вважаю, що мають дуже великі шанси. Тому що вони прості. Якщо ви не знаєте про сигнали, це зараз візьміть і поцікавтеся ними. Сигнали мають дуже великий шанс стати, як проміси колись, частиною екосистеми JavaScript. Тому що є вже такі кулуарні обговорення в комітеті TC39. Тому що очевидність того, що система JavaScript потребує базового примітиву реактивності, така ж, як було очевидно 10 років тому, що екосистема JavaScript потребує базового примітиву асинхронності, як було з промісами. Тому сигнали — це добре.

А команда React — що? А вона каже, що ми підемо своїм шляхом. React forget. Ну що, що там буде у 2024-му, я не знаю. Але якщо вам цікаво, що я зараз рекомендую обирати, я своїм людям зараз рекомендую обирати, якщо ви хочете залишатися дотичними до екосистеми React, Solid. Якщо вам просто треба взяти якийсь фреймворк, зберіть. Ви знаєте, що я з великої трійки, мені зараз з усіх більше за все подобається Vue. Він реально став виріс, в ньому є типізація, дженерики, ефективний пересічний код на Vue набагато швидший, ніж пересічний код на React. Набагато. Тобто я хочу писати бізнес-логіку, і щоб мені безкоштовно давали швидкодію. Якщо вам треба трошки більше керованого ентерпрайзу — Angular.

Це далеко не всі зміни, які будуть в Angular. Просто вони ще не всі доїдуть. Десь ще 2-3 версії заїдуть. Але Angular — це, по-перше, надійність, по-друге, дуже легке оновлення. Тільки подумайте, 40% кодових баз Angular, за статистикою команди Angular, використовують останню версію Angular. Це надзвичайно суттєве досягнення. Це дуже круто. От. І, чесно кажучи, я не можу зараз відповісти, чому я можу брати зараз React. Я не звик у TypeScript-проектах. Зараз. Хочу вірити, що це зміниться. Тому що конкуренція розвиває. Але подивимося, як то воно буде. Все.