Нещодавно ми з командою працювали з клієнтом з фінансового сектора: у нього є сайт і особистий кабінет, давно написані на PHP (бек і фронт), і завдання — оновити дизайн і користувацький досвід без глобальних змін «під капотом».
Ми почали досліджувати, наскільки доцільно зараз підтримувати фронт на PHP. Поки розбиралися, зібралося багато аргументів і спостережень. Ділимося ними, щоб допомогти компаніям і розробникам, які опинилися в такій же ситуації.
Як загалом справи з PHP
Для розробки інтерактивних інтерфейсів PHP вже не застосовують, бо з'явилися варіанти кращі. Ми порівнюємо з React, бо використовуємо його на інших аналогічних проєктах. Але в це ж порівняння підуть і Vue або Angular. Все це зручні інструменти для роботи з динамічним UI.
На нових проєктах у ролі фронту PHP практично не використовують. Якщо він зустрічається, то це спадщина, від якої поступово відходять. При цьому PHP на бекенді все ще дуже популярний, з'явилися фреймворки (Laravel, Symfony), строга типізація тощо, що робить його хорошим інструментом для серверної логіки.
Коли PHP-фронт працює нормально
Чесно: з простими завданнями PHP-фронт справляється на «ура». Корпоративний сайт-візитка, лендінг, форма зворотного зв'язку — тут немає складної логіки, оновлення даних відбуваються рідко, а навантаження мінімальне.
У таких випадках краще дійсно дати фронту пожити і не витрачати зайві ресурси.
Де починаються проблеми
Ситуація змінюється, щойно додаток стає складнішим. Наприклад, в особистому кабінеті з'являються калькулятори, форми оплати, завантаження і підписання документів. Тут PHP-фронт поводиться не так, як хотілося б: будь-яка дія користувача призводить до перезавантаження всієї сторінки. Навіть якщо оновився тільки маленький блок, доводиться чекати повного рендеру. І це негативно позначається на швидкості роботи додатка.
Для користувача, звиклого до швидкості сучасних мобільних банків або маркетплейсів, це виглядає сумно. І в кінцевому підсумку впливає на загальне враження від сервісу і на лояльність клієнтів.
Чим відрізняється підхід React
Далі будемо розглядати саме на його прикладі, просто бо добре знайомі. React вирішує проблеми продуктивності архітектурно. Він працює компонентно: змінюється тільки той участок інтерфейсу, де відбулася дія. Якщо клієнт змінює параметр в калькуляторі або прикріплює файл, сторінка не перемальовується цілком, а оновлюється тільки потрібний блок.
Для користувачів це означає швидкий відгук і більш живий інтерфейс.
Реально заощадити, якщо переходити на React?
Хотілося б навести статистику по вже реалізованому проєкту, але поки її немає — є попередні розрахунки.
Ми очікуємо, що з переходом на React:
- Середній час розробки нової функції скоротиться на 40–50%
- Підтримка стане простішою. Компонентний підхід і автотести дозволяють швидше знаходити і виправляти помилки, що зазвичай призводить до економії на багфіксах і QA в межах 30–35%.
- Бізнесу вдасться заощадити близько 20% бюджету на рік з прискоренням релізів і оптимізацією витрат на розробку і тестування.
Бонус: React — фундамент для PWA
Можливість розгорнути Progressive Web App не вирішальний аргумент. Але може знадобитися в кількох випадках:
Застарілий мобільний додаток або втрачено доступ до нього. PWA може замінити нативний клієнт. Користувач отримає швидкий доступ до додатка прямо з іконки на екрані смартфона, без завантаження з App Store або Google Play.
Тут важливо, що більшість нативних сценаріїв вже можна реалізувати в PWA: push-повідомлення, офлайн-доступ, інтеграцію з камерою для завантаження документів або електронний підпис.
Коли немає бюджету на натив. Розробка повноцінних мобільних додатків вимагає великих ресурсів. У таких випадках PWA стає компромісом: єдиний додаток працює в браузері і при цьому дає звичний досвід і доступ до потрібних функцій.
Переведення React-додатка в PWA — це не окремий проєкт на місяці, а доопрацювання, яка в середньому займає тиждень роботи одного досвідченого розробника.
Підсумок
Історія з редизайном показала нам просту річ: іноді фронт на PHP дійсно можна залишити, якщо йдеться про простий сайт. Але щойно додаток стає складним, такий вибір починає гальмувати розвиток бізнесу.
React дає можливість будувати сучасні інтерфейси, швидше випускати нові функції, знизити витрати на підтримку і підготувати ґрунт для PWA.
Якщо ви плануєте розвивати цифровий сервіс, рано чи пізно питання «переписувати чи ні» все одно постане. І чим раніше ви почнете цей шлях, тим простіше він пройде.
Доводилося вам вирішувати подібні завдання? Буде цікаво почути досвід в коментарях.
Коментарі