Next.js часто выбирают потому, что «так принято». Нам он нужен по другой причине: продукт должен одинаково хорошо открываться человеку, поисковику и следующей версии команды.
Клиентский SPA отлично работает внутри сессии. Он хуже стартует с холодного захода, хуже индексируется и быстрее обрастает состоянием, которое никто не контролирует. Для студийного сайта, кабинета и контента это разные задачи. Фреймворк должен их разводить, а не смешивать в одном бандле.
Что оставляем на сервере
Маршруты, метаданные, статьи, карта сайта, доступ в админку — это сервер. Там проще держать секреты, проще отдавать HTML, проще не тащить на клиент то, что посетителю не нужно.
Клиенту оставляем то, что живёт от жеста: меню, плеер, трекинг, интерактивные колоды. Если анимация или форма не требуют браузера, их не стоит делать клиентским островом «на всякий случай».
Где ломается рост
Рост ломается не на выборе библиотеки. Он ломается, когда данные живут в пяти местах, а страницы знают слишком много друг о друге. Статья зашита в компонент главной. Админка правит другой файл. Аналитика смотрит в третий. Через полгода любое изменение — раскопки.
Нормальная основа выглядит скучно: один источник контента, явные маршруты, пересборка только там, где контент изменился. Тогда инсайт можно опубликовать из панели, и он появится на главной, в ленте и в sitemap без ручной склейки.
Практическое правило
Мы собираем продукты так, чтобы первую версию было не стыдно показать, а вторую — не стыдно продолжать. Next.js здесь не фетиш. Это способ держать сервер и клиент в разных ролях, пока продукт ещё маленький, и не переписывать фундамент, когда появятся статьи, кабинет и учёт трафика.