Навіщо використовувати React?
Це не риторичне питання. Я дійсно хочу знати, чому розробники обирають створювати вебсайти за допомогою React.
Є багато можливих причин. На жаль, жодна з них безпосередньо не стосується досвіду користувача, окрім як опосередковане виправдання: "щасливі продуктивні розробники створюватимуть кращі вебсайти".
Також варто зазначити, що деякі люди не обирають використовувати React, а його використання є обов'язковим на їхньому робочому місці (як і деякі інші новітні технології, які я міг би згадати). Згідно з моїм визначенням, це робить React корпоративним програмним забезпеченням у цій ситуації. Моє визначення корпоративного програмного забезпечення - це будь-яке програмне забезпечення, яке ви використовуєте, але яке ви самі не обирали.
Інерція
Безумовно, найпоширенішою причиною вибору React сьогодні є інерція. Якщо це те, з чим вам комфортно працювати, вам потрібна справді переконлива причина, щоби його не використовувати. Зазвичай це також є причиною мандатів на його використання. Якщо ми «стандартизуємо» React, це спростить найм (хоча реальність не така проста, оскільки екосистема React з часом мутувала й розгалужувалася).
І знаєте що? Інерція - це абсолютно обґрунтована причина для вибору технології.
Якщо час має вирішальне значення, і ви знаєте, що вивчення нової технології займе у вас багато часу, має сенс дотримуватися того, що ви вже знаєте, навіть якщо це застаріло. Це стосується не лише React, а й будь-якого технологічного стека.
Усе це було б абсолютно добре, якби React не був фреймворком, який виконується в браузерах. Будь-який клієнтський фреймворк - це навантаження на кінцевого користувача. Їм доводиться завантажувати, розбирати та виконувати фреймворк, щоб ви могли отримати переваги.
Але, можливо, React взагалі не потрібно запускати в браузері. Це обіцянка рендерингу на стороні сервера (Server-Side Rendering, SSR).
Фронтенд
Раніше існував досить чіткий поділ між фронтенд-розробкою та бекенд-розробкою. Фронтенд складався з HTML, CSS і клієнтського JavaScript. Бекенд був чим завгодно, аби він міг віддавати ці складові фронтенду: PHP, Ruby, Python, або навіть просто звичайний вебсервер зі статичними файлами.
Потім стало можливим писати JavaScript на бекенді. Чудово! Тепер не потрібно було перемикати контекст, коли ви писали скрипти для клієнта чи сервера. Але це благо також виявилося частково прокляттям.
Коли ви пишете код для бекенду, деякі речі важливіші за інші. Наприклад, розмір файлу насправді не є проблемою. Ваш код може стати дуже довгим, і це, ймовірно, не уповільнить виконання. А якщо й уповільнить, ви завжди можете вирішити цю проблему, купивши потужніший сервер.
На фронтенді ваш код повинен мати інші пріоритети. Розмір файлу має значення, особливо для JavaScript. Код не виконується на вашому сервері. Він виконується на всіляких мережах, браузерах та пристроях. Якщо щось сповільнюється, ви не можете вирішити проблему, купивши кожному вашому користувачеві новий пристрій і новий тарифний план мережі.
Тепер, коли JavaScript може працювати як на сервері, так і на клієнті, є спокуса просто ставитися до коду однаково. Зрештою, це та сама мова. Але контекст справді має значення. Деякий JavaScript, який чудово працює на сервері, може бути ненажерливим споживачем ресурсів на клієнті.
І тут починається саме цікаве в контексті React. Тому що більшість речей, які подобаються людям у React, все ще застосовуються і на бекенді.
React-розробники
Коли React вперше з’явився, його рекламували як фронтенд-інструмент. Управління станом і майже магічний віртуальний DOM були головними перевагами.
З часом це змінилося. Заявлені переваги у швидкості віртуального DOM виявилися просто хибними. Залишилося лише управління станом.
Але зараз переваги змінилися. Архітектура на основі компонентів виявилася справді популярною. Розробникам сподобався JSX. Дуже сподобався.
Як тільки до нього звикаєш, це стає чудовим засобом обʼєднати невеличкі функціональні можливості в будівельні блоки, які можна комбінувати різними способами.
Довгий час я не усвідомлював, що це сталося. Я все ще думав про React як про бібліотеку, на кшталт jQuery. Але React - це фреймворк, як Rails чи Django. Як розробник, це місце, де ви виконуєте всю свою роботу. Чорт забирай, це майже ваша ідентичність.
Але якщо Rails чи Django працюють на бекенді, то React працює на фронтенді …за винятком випадків, коли це не так.
JavaScript може працювати на сервері, а отже React теж може працювати на сервері. Цілком можливо і надалі користуватися всіма перевагами React. Ви можете писати весь свій код у React, не віддаючи користувачам жодного рядка React.
У теорії це так. Але диявол криється в інструментах.
Пріорітети
Next.js дозволяє писати на React і виконувати серверний рендеринг. Але він дуже, дуже хоче віддавати React-код на клієнт.
За замовчуванням ви отримуєте сумнозвісний патерн гідратації (hydration pattern) - виконати всі обчислення на сервері в JavaScript (ура!), одразу віддати HTML (ура! ура!) …а потім ще й віддати весь той самий JavaScript, який і так уже виконувався на сервері (ура - стоп, що?).
Можна змусити Next.js пропустити цей останній крок, але це непросто. Вам доведеться боротися з цим на кожному етапі.
Astro пропонує зовсім інший підхід. Він робить усе можливе, щоб мінімізувати JavaScript на клієнті. Розробники можуть і далі користуватися улюбленим JSX-середовищем, не завдаючи шкоди користувачам.
На жаль, колективна інерція "сучасної" спільноти розробників міцно прив’язана до екосистеми React/Next/Vercel. І це прикро, адже Astro показує, що все зовсім не обов’язково має бути так.
Перехід від React на фронтенді зовсім не означає, що вам потрібно відмовлятися від React на бекенді.
Навіщо використовувати React?
Питання, яке я поставив у заголовку, надто широке й надто наївне. Є безліч причин використовувати React, так само як є багато причин використовувати WordPress, Eleventy або будь-яку іншу технологію, що працює на бекенді. Якщо це те, що вам подобається або з чим вам зручно - цього вже достатньо.
Мене ж насправді хвилює лише фронтенд. Я не збираюся засуджувати чийсь вибір серверного фреймворку, доки він не впливає на те, що ви можете робити в клієнті. Як каже Гаррі:
…якщо ви збираєтесь його використовувати, я не маю це відчувати.
Ось питання, яке я насправді повинен ставити:
Навіщо використовувати React у браузері?
Якщо ваша причина використовувати React - культурна (вся команда пише на JSX, так легше наймати людей), тоді, ймовірно, немає потреби змушувати користувачів завантажувати React.
Якщо ви створюєте SPA, то …ну, спершу запитайте себе, чи справді це має бути SPA. Вони повинні бути скоріш винятком, ніж стандартом. Але якщо ви все ж таки налаштовані робити SPA, тоді я розумію, чому керування станом стає дуже важливим.
У такій ситуації спробуйте використовувати Preact замість React. Як розробник, ви майже напевно не відчуєте різниці, але ваші користувачі оцінять приємну відсутність зайвої ваги.
Але здебільшого я б заохочував вас дослідити, на що здатен звичайний JavaScript у браузері. Я цілком розумію бажання триматися за React як авторське середовище, але не дозволяйте фреймворку обмежувати те, що ви можете робити на фронтенді. Якщо ви використовуєте React у клієнті, ви не робите своїм користувачам жодної послуги.
Ви можете продовжувати писати на React. Ви можете продовжувати використовувати JSX. Ви можете й надалі наймати React-розробників. Але тримайте це на своєму комп’ютері. А для користувачів використовуйте максимум того, на що здатні веб-браузери.
Коли ви залишаєте React на сервері, перед вами відкривається цілий світ можливостей у клієнті. Веб-браузери стали неймовірно потужними у тому, що вони сьогодні пропонують. Не дозволяйте React на стороні клієнта стримувати вас.
А якщо хочете дізнатися більше про те, на що здатні сучасні веб-браузери, приходьте на Web Day Out у Брайтоні, у четвер, 12 березня 2026 року.