Рендеринг на стороне сервера – SSR, разве это не то что всегда делал PHP?

Это примерно выглядит так:
Стадия 1:
- Рендеринг на сервере говно, так рендерят лохи, да здравствует SPA
Стадия 2:
- Ну да, с SPA много проблем. Так делают лохи. Да здравствует SSR
Но соль в том, которую обычно упускают, что код рендеринга SPA и SSR - один - JS

Правильно прочитай фразу)) - типа генерация кода веб страницы на стороне сервера - статистической HTML страницы на сервере. Т.е посетителю при запросе отдается готовый HTML файл

Погрузись в тему например: Headless WordPress & Astro, будет более понятно. Ну или совсем крыша поедет🤣


PS Мой вывод, это когда спецы по JS, предлагают отдавать клиенту страницы не WP (PHP), а готовые сгенерированные HTML страницы.
Т.е извиняюсь через большую Ж..., мотивируя улучшением скорости загрузки, и безопастностью, так как нет доступа к WP и базе, а отдается статика

Твой вывод  о чем? Браузер не знает ни про какой WP/PHP/Python и прочее - он не умеет ничего кроме JS/HTML. Речь идет о фреймворках типа Vue, которые отдают в браузер JS код, который потом рендерится мощностями клиента, а не сервера. Вот  и SSR предлагает концепцию отдачи HTML в браузер. 

По сути Дмитрий прав - то же самое что делает любой PHP фреймворк.

Ну, да, это я себе так представляю, вот есть же у меня тема для WordPress’а, да и сам вордпресс, там есть код, он интерпретатором создает/генерирует подготавливает html страничку, отдает её веб-серверу, а тот клиенту, то есть так-то это и есть типа ssr рендеринг на стороне сервера, он же php не на стороне клиента это делает.

Но, у них я так глянул, нужно node.js и ещё кучу библиотек, какие-то утомительные подходы, чтобы по сути сделать тоже самое что и php в базе, ну в смысле для ssr. Другой вопрос что там еще механизмы аякса, реактивного подхода, ну типа что бы страничка не перезагружалась, но по сути рендеринг на стороне сервера это же просто php (ну или другой язык – python, ruby, asp, java, go до них говорят и Perl был для этих же целей).

Есть нюанс. Обычно при использовании этого термина (SSR) код сайта поддерживает оба вида "рендеринга", например при "первом запросе" - SSR, а потом уже на клиенте. Кроме того, SSR - это не только генерация страницы целиком, например посредством SSR может генерироваться основной блок страницы и передаваться на клиент вместе с другими данными для встраивания в нужные места страниц, причем этот "микс" может передаваться как в одном ответе, так и в нескольких.

PHP and Node.js имеют свои сильные  и слабые стороны. Если не понятно для чего нужен node.js, то он вам не нужен - просто используйте пхп )

Программист)) Знаешь почему никакой, данные придумываются и логики ноль
Ткни где в ответе про браузер?

Чтобы в п.2, не было как у них утомительно:
2. Включи кэширование полностью для всех страниц, и отдавай на запрос страницу из кэша, получишь тоже самое

В первом случае WP ( php) создает страницу и отдает клиенту
Во втором случае страница уже создана (  Статический сайт)  и она отдается клиенту из файла ( статическая HTML страница)
Разберись с понятиями.

Ничего сложного во фреймворках нет, просто выдумано через Ж - в этом ты прав:
какие-то утомительные подходы, чтобы по сути сделать тоже самое что и php в базе

Ну кеширование — это понятно, оно понятное дело включено, и отдается полностью подготовленная страница html, но даже без этого по сути на стороне сервера генерируется/создается страница html и отдается пользователю, а-ля ssr, рендеринг на стороне сервера, ведь пользователь уже получает готовый результат, даже без кэша если.

Взгляните на вопрос несколько глубже. SSR тут вообще не центральный вопрос.

В первую очередь это разделение разработки бека и фронта. И когда над проектом работает команда, то получается серьезный профит. За счет распараллеливания разработки. Т.е. вначале договорились об АПИ взаимодействия. Создали документ его описывающий и далее ведем разработку параллельно.  Ранее грани между фронтом и беком были размыты. Что могло вносить проблемы в разработку (грубо говоря: верстальщик подшаманил в файле, потом бек туда же залез и т.п).

Хороший выход получился со SPA, Но тут возник вопрос, что это не годится для сайтов где есть вопросы СЕО. А таким сайтам уже тоже захотелось такого разделения. Вот и появилось понятие SSR для них. Которое решает эту проблему.

Что до производительности. Да есть профит, и не только в отдаче типа статических html (все равно на том же интернет магазине есть достаточно динамики). Тут есть тонкости в том как отдает страницу нода. (тут лучше почитать об этом более подробные статьи если интересно)

А от разделения у нас есть еще один профит. Теперь фронту по барабану что там на беке захтели с wp переделали на битрикс, захотели вообще на Go или java мигрировали. (или вообще один сервис так другой так)

Сам я фулстек. По сути мне удобнее когда  только PHP.  Но, скажем, Лк для клиентов (что то типа биллинга) я на своем сайте сделал работающий прототип на реакте, сейчас на чисто на вью пишу. И в принципе тоже есть профит (субьективно). как минимум в дополнительном упорядочивании. Но биллинг как раз тот случай, когда SSR не обязателен.

Короче: SSR нет смысла спрашиать , чем он "лучше PHP".  Т.к. сравнение идет несколько в другой плоскости. и SSR это лишь следствие того самого выбора

Разберись, что такое готовый. результат) И не зря советовал почитать и разобраться Headless WordPress & Astro. А лучше на практике.

Если грубо: Берем WP и берем Headless WP, в обоих случаях обработка за счет PHP, изначально. Затем:

В первом случае: Кэширование создает статические страницы ( HTML файлы) и записывает на сервер. Сэр - файлы HTML для выдачи клиента без PHP.

Во втором случае, Astro создает статические страницы ( HTML файлы) и записывает на сервер. Все страницы сайта. Чтобы изменить -необходимо пересобрать все статические страницы сайта

Так понятно?
А если без кэширования и без Astro, то WP PHP при запросе создает и выдает HTML страницу динамически.
Динамика или статика.

Думаю - это слишком глубоко для понимания ТС