React на сервере — это не PHP

Привет, Хабр.

Некоторое время назад наткнулся на интересную статью в блоге Кристофера Артмана, которой он сравнивает до чего эволюционировал Реакт в наше время и задается вопросом, о том, не вернулись ли мы в отправную точку, и Реакт на сервере — это старый добрый PHP.

Кроме самой статьи мне интересно было почитать комментарии к ней. И там довольно большое количество людей не согласилось с автором.

Под катом Вы найдете вольный перевод (или даже рерайт) этой статьи, а с оригиналом можно ознакомится по ссылке.

Серверный JavaScript — это просто PHP с новыми обертками?

Возвращение серверного рендеринга (SSR) в мире JavaScript породило бурные обсуждения среди разработчиков. «Разве это не просто PHP на новый лад?» — задаются вопросом скептики. На первый взгляд сравнение может показаться уместным, но в действительности все гораздо сложнее и интереснее.

Давайте разберемся, почему современный серверный JavaScript — это не шаг назад, а огромный скачок вперед в разработке мощных и эффективных веб-приложений.

Вспоминая PHP: простота былых времен

Когда-то, в эпоху Internet Explorer, PHP был основным инструментом для создания серверной логики. Мы писали серверный код, генерировали HTML на лету и отправляли его пользователям. Всё казалось таким простым. Но тогда и задачи были куда менее амбициозными. Мы решали небольшие проблемы, создавали статичные страницы или примитивные блоги.

Типичный стек включал серверный язык (PHP, Java или даже Perl), рендеринг HTML на сервере и минимум JavaScript на клиенте. Интерфейс был довольно простым, а интерактивность добавлялась точечно, с помощью «ненавязчивого JavaScript» — помните такое? 😊 Тогда мы избегали писать слишком много JS, и это было скорее облегчением, чем ограничением.

Но мир менялся. Мы хотели большего: более сложных приложений, интерактивности и удобных интерфейсов. JavaScript стал центральным языком веба, и мы не могли этого игнорировать.

Почему мы ушли от серверного рендеринга

Когда приложения становились сложнее, старые подходы начали трещать по швам. Представьте себе блог с системой комментариев. На сервере вы рендерите все комментарии в HTML. А теперь добавьте нового комментария с клиента: нужно либо заново прописывать HTML-структуру в JavaScript, либо использовать хитрые трюки вроде скрытых шаблонов. Это был настоящий головняк, особенно если HTML-классы менялись.

Более того, императивный подход к созданию интерфейсов (когда вы напрямую управляете DOM) оказался крайне неудобным. Нам нужен был декларативный подход и компоненты, чтобы состояние и UI всегда оставались синхронизированными.

Вот так мы пришли к клиентским приложениям (SPA). Они дали нам богатую интерактивность и гибкость… но вместе с ними и новый набор проблем.

Проблемы SPA: назад к серверу?

Полный перенос логики на клиент привел к множеству трудностей:

1. Навигация. Простые URL с серверным рендерингом сменились сложными роутинг-фреймворками. Да, мы получили такие фишки, как сохранение состояния между страницами, но какой ценой? Сколько «ссылок» вы видели, которые по сути были кнопками с onClick? 🤦‍♂️

2. Производительность. Устройства пользователей теперь обрабатывали весь интерфейс. Рендеринг пустого div с подключением скрипта для каждой страницы плохо сказывался на SEO и скорости загрузки.

3. Разделение команд. SPA усилили разрыв между фронтенд- и бэкенд-разработчиками. Раньше мы все были «веб-разработчиками» и работали на всех уровнях стека. Теперь же это разделение ухудшило коммуникацию и, как следствие, качество конечного продукта.

Современные фреймворки: не шаг назад, а движение вперед

Но вот хорошие новости: мы возвращаемся к серверу, но не к PHP. Современные фреймворки вроде Next.js, Remix и SvelteKit позволяют использовать единую экосистему JavaScript для разработки. Мы рендерим UI на сервере, но делаем это декларативно, с помощью компонентов и состояний.

Может показаться, что React Server Components с SQL-запросами похожи на старый добрый PHP с его смешением HTML, CSS и SQL. Но главное отличие в том, что мы больше не создаем «спагетти-код». Мы используем проверенные временем принципы разработки UI и современные инструменты.

Фреймворки также стирают границу между фронтендом и бэкендом. Теперь один разработчик может реализовать функциональность «от и до»: от запросов к базе данных до UI-интеракций. Это не только упрощает процесс, но и делает продукты более целостными и оптимизированными.

Новый рассвет веб-разработки

Сегодня мы берем лучшее из мира PHP и усиливаем это мощью современного JavaScript. Мы можем строить амбициозные приложения, используя сервер не только для сериализации JSON, но и для оптимального рендеринга.

Это также возвращает нас к идеалу «фулстек-разработчика», только теперь у нас есть инструменты, чтобы делать это красиво и эффективно. Если вы чувствуете, что застряли в рамках «фронтенда» или «бэкенда», самое время расширить горизонты и стать мастером на обеих сторонах стека.

Мы прошли долгий путь от вставок PHP в HTML. Да, это может выглядеть похоже на поверхности, но теперь мы строим на основе многолетнего опыта и лучших практик.

Заключение

А что вы думаете об этой тенденции? Уже используете фуллстек JavaScript-фреймворки? Или все еще держитесь за PHP? Пишите в комментариях, обсудим! 🚀

А если вам интересны современные подходы в разработке, вы хотите больше узнать о JavaScript, трендах и интересных проектах, приглашаю в мой Telegram-канал! Там я делюсь опытом, новостями и полезными материалами, а еще стараюсь сделать контент не только информативным и интересным.

Присоединяйтесь: https://t.me/+qbK9ZPuAocI2MWUy 👾