Версионирование API. Я слышал истории о людях, которые никогда не закрывают свой компьютер или браузер и держат одно и то же SPA открытым месяцами. Они никогда не получают обновленную версию клиента, потому что никогда не обновляют страницу.
Валидация. Если вы пользуетесь SPA, вам необходимо дублировать правила, уже заданные языком программирования, на котором написан ваш бэкенд, в JavaScript или TypeScript.
Безопасность. При использовании SPA клиентское приложение вынуждено решать, какой HTML отображать, на основании входных данных в формате JSON.
Безопасное скачивание файлов. Предоставление пользователю права на скачивание файла в приложении, использующем SPA — это на удивление нетривиальная задача.
Документация. При использовании SSR документация становится не нужна, поскольку HTML и CSS становятся частью серверной стороны приложения.
Переводы. Переводы можно сделать исключительно на фронтенде, и на первый взгляд это кажется логичным выбором. Однако, если вам потребуется сделать пагинацию на сервере, переводы тоже придется перенести на бэкенд.
Медленная первая загрузка. В случае с рендерингом на сервере, отправляется только тот HTML код, который необходим для отображения страницы.
Реализация поведения браузера заново. При использовании SPA (будь это React, Angular или Vue), кнопка Back из коробки не работает.
Моментальные появления неверных состояний. Вы когда-нибудь встречали веб приложение, где изначально появляется что-то одно, но через секунду или две, появляется что‑то другое или что‑то одно заменяется на что‑то другое? Скорее всего, это приложение является SPA.
Состав команды. При работе над приложением с рендерингом на стороне сервера людям проще работать над всем приложением в целом. Специализация все еще будет присутствовать, в том смысле, что кого-то всегда будут просить проконсультировать по сложным проблемам с CSS, по тому же принципу, что кто-то в команде всегда помогает другим решать проблемы с базой данных.
Публичные и приватные API. Если вы разрабатываете веб приложение с рендерингом на сервере, и у вас есть выделенный API только для мобильного приложения, становится очевидно, какая часть должна считаться приватной, а какая является публичным API. Если вы следуете практике написания кода, при которой контроллеры являются очень тонким слоем и просто делегируют сервисам или сценариям использования, тогда никакого дублирования происходить не должно.
Добавляйте сложность только тогда, когда она нужна. Если вы используете SSR с htmx, вы можете начать с простого HTML и CSS.