«Це революція»: React та Next.js померли — і новий фреймворк готовий їх замінити

Здається, це початок наступної революції для JavaScript Framework. Про це у своєму блозі на Medium пише Сомнатх Сінгх. Передаємо йому слово.

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

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

Ви не зможете оминути JavaScript. Усвідомте це та полегшіть своє життя.

Безлад, у якому ми перебуваємо

Маси завжди помиляються… Мудрі роблять те, чого не робить натовп. Змініть те, що вони вивчають і ви отримаєте омріяне — те, що вони шукають.

(Чарльз Буковскі)

Нам важко визнати, що те, що зараз відбувається у веброзробці — це звичайний безлад. Ми давно дійшли висновку (і це було грубою помилкою), що надсилання HTML (від клієнта до сервера) надто дороге, і почали розробляти ще гірші альтернативи.

Всі ці роки ми розробляли різні фреймворки: ми руйнували фундамент, на якому будувався веб.

Зараз я поясню, що саме маю на увазі.

У типовій вебпрограмі ми надсилаємо клієнту відрендерений на боці сервера HTML, а клієнт рендерить його (до того він інертний) — і ви не можете з ним взаємодіяти. Наступне, що робить браузер: він завантажує програму (частини JavaScript) для вашої сторінки. І, нарешті, він виконує програму — ви можете взаємодіяти з ним прямо зараз.

Незважаючи на те, що ми надіслали клієнту всю структуру, все одно потрібно чекати, поки вона стане інтерактивною.

Час запуску безпідставно збільшується. Напевно, це проблема, чи не так?

Чому вебсайти так довго завантажуються? Основна причина — це те, що вони мусять щоразу починати з нуля.

Ми називаємо це гідратацією (так, знаю, звучить химерно) — мається на увазі, що браузер читає частини JavaScript і визначає, які розділи коду чому відповідають на вебсторінці.

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

Після того, як ми надсилаємо серверний HTML, а клієнт завантажує та виконує його, ми намагаємося відкладено завантажити вебпрограму окремими фрагментами.

І вгадайте, що відбувається?

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

Проблему задля вирішення якої ми використовували лініве завантаження, так і не вирішено. Лініве завантаження корисне лише в системах, що вже існують, і для компонентів, яких зараз не знаходяться в вашому дереві візуалізації (в цьому випадку вам не потрібен контекст).

Для компонентів, які зараз є у вашому дереві візуалізації, лініве завантаження — це відволікання.

Люди цього не усвідомлюють. Коли ви кажете, що ваша програма занадто велика, вони вигукують: «І що? Просто використайте ліниве завантаження і все буде добре».

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

У нас також є ці острівні архітектури (популяризовані Astro). Де замість того, щоб гідратувати все на початку, ми гідруємо, коли клієнт взаємодіє з конкретним компонентом. Якщо я взаємодіяв з меню, я гідрую лише його, якщо я взаємодію з будь-якими конкретними компонентами — я гідрую лише їх, а не всю програму.

Це вже краще. Але ці острови все ще досить великі. І зв’язок між ними стає проблемою, тому що ви просто перетворили свій компонент на острів, острів — це програма. Тепер у вас є проблема зв’язку між програмами, яку потрібно якимось чином вирішити.

І тут на сцену виходить Qwik.

Коли я взаємодію з певним компонентом, вирішується лише цей конкретний компонент.

Зауважте, що в цьому випадку не потрібно було вирішувати ні батьківські, ні дочірні частини компонента на відміну від того, що відбувається при використанні Astro.

Qwik каже: «Мені потрібно зробити лише це і більше нічого».

Qwik також достатньо розумний, щоб розпізнавати, коли один компонент залежить від іншого (уявіть кнопку «додати в кошик» у e-commerce застосунку) і активувати залежний компонент.

Давайте відкриємо вкладку Network: тут немає JavaScript на початковому завантаженні сторінки.

Відсутність JavaScript у цьому випадку не надто вражає. Це може зробити будь-який фреймворк (якщо ви просите статичну сторінку).

Що робить Qwik особливим: він зрозумів це самостійно. По суті, він просто переглянув ваш код і сказав: «Насправді вам тут не потрібен JavaScript, я навіть не збираюся надсилати його». Ви помітите, що JavaScript не завантажується, доки ми не натиснемо кнопку.

«Бризки» JS перетворюється на водоспад. Але не зважаючи на це, час завантаження не буде збільшуватись. Qwik дозволяє писати стільки коду на JavaScript, скільки забажаєте. І вам не треба бентежитись про зниження продуктивності.

Крім того, він досить розумний, щоб попередньо завантажувати файли у фоновому режимі для користувачів у повільних мережах.

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

Винахідливість часто маскується під магію

Це був такий чарівний момент, коли я дізнався про віртуальні машини. Я думав: «Хіба таке можливо? Як можна запустити OS всередині OS?». Але те, що здавалося мені магією, було просто технологією.

Я міг завантажувати Linux всередині моєї машини з Windows: для мене це було неймовірно.

Але найбільше мене вразило не це. Ви можете завантажити Linux, увійти, відкрити програму (скажімо, текстовий процесор) і почати вводити текст, а потім у якийсь момент ви збережете віртуальну машину, візьмете збережений файл і надішлете його своєму другу. Коли мій друг відкриває файл і відновлює машину, він опиняється саме там, де я зупинився.

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

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

Власне, якщо ви розмірковуєте, чому вебсайти запускаються повільно, то причина в тому, що вони мають завантажитись. Пам’ятаєте про гідратацію? 

Чому ж програми Qwik швидко запускаються? Тому що вони пропускають етап завантаження і переводять вас у той момент, який був на сервері, коли ви зупинились минулого разу. 

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

«Найкращий код — це відсутність коду взагалі»

Qwik швидкий не тому, що дуже ефективний, а тому, що чудово уникає зайвої роботи.

Він пропонує абсолютно нову парадигму візуалізації, що називається «можливість відновлення» і усуває потребу в гідратації. 

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

Qwik відкриває безліч нових можливостей. Ви можете, наприклад, рендерити свою сторінку на кількох серверних периферійних службах і зібрати її як єдину відповідь.

Висновок

Тисячі років тому Гаутама Будда рекомендував обирати серединний шлях. Але ми, розробники, надто вперті: весь час впадаємо в крайнощі.

Одні кажуть вам використовувати JavaScript (для SPA), інші радять взагалі не мати з JS справу (фреймворки на основі WebSocket, як-от LiveView). А решта дозволяє вам використовувати JS за рахунок розміру комплекту (і за рахунок продуктивності).

Qwik — це ковток свіжого повітря в усіх цих випадках. Він зовсім не схожий на те, що ми коли-небудь використовували раніше.

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

Текст адаптувала Євгенія Козловська