Comments 22
При использовании сервера выше производительность, поскольку HTML уже сгенерирован и готов к отображению при загрузке страницы.
Производительность ниже, так как каждому клиенту надо отрисовку делать на сервере. Нагрузка на сервер. Нет адаптивности и отзывчивости, которую может дать javascript.
При рендеринге на стороне сервера выше совместимость, поскольку, опять же, HTML генерируется на сервере и не зависит от конечного браузера.
Это как раз дает низкую совместимость, так как нет возможности пользоваться проприетарными фишками браузеров. Веб застрянет на старых стандартах. Прогресс на фронте будет отставать года на три-четыре. Будет кринж на старых браузерах
Сложность ниже, потому что сервер выполняет большую часть работы по генерации HTML, поэтому часто может быть реализован с более простой и меньшей кодовой базой.
Сложность невообразимо выше. По сути пишешь сайт два раза двумя способами. Первым - нормальным (клиент-сервер, фронт-апи бэк), и вторым через одно место
Так и не дан ответ - зачем он нужен, этот ваш SSR. Ради чего все эти мучения?
Утверждения о том, что SSR что-то там упрощает являются однозначным и 100% признаком развешиваемой по ушам лапши. Каждый, кто хотя бы издалека это щупал, знает, что SSR намного медленнее, сложнее и дороже в разработке и обслуживании чем классические динамические страницы. И р этом ещё и менее гибкий, так как сложнее сделать что-то брузеро- или плафтормо-зависимое уж, если захочется. И всякие чудеса вроде адаптивной верстки в зависимости от конкретной платформы, если вашу вдруг возможностей CSS не хватает или хочется чего-то совсем необычного, сложнее сделать. Есть кто-то говорит иначе - смейтесь над ним и гоните прочь.
У SSR был ровно один плюс, ради которого он был создан - он хорошо индексируется. Всё остальное было минусами и компромиссами. Именно ради этой фичи бизнес во главе с SEO пошёл на дополнительные затраты на разработку и серверные мощности. Никаких иных плюсов там нет и быть не может, только минусы, которые в некоторых случаях уравновешиваются одним единственным вышеупомянутым плюсом.
Но с тех пор поисковики научились в динамические страницы, а программисты научились уменьшать время до первого рендеринга DOM. Правилом хорошего тона уже считается выдать предварительную вёрстку сразу после события окончания загрузки DOM, поисковики умеют пропускать ненужные этапы загрузки страницы, а разработчики умеют делать страницы, которые грузятся без шрифтов, лишних стилей, таймеров и прочих излишеств и умеют подгружать необязательный функционал в фоне. В результате SSR в его современном виде оказался ненужен чуть более чем полностью. А в тех редких случаях, когда он действительно нужен, на самом деле нужен не модный SSR, а старые добрые серверные шаблоны.
Но процесс оказался запущен. Выросло поколение специалистов по SSR, которые творят его везде и рассказывают от непомерной крутости. Но на вопрос "зачем?" они ответь не могут, так как они освоили SSR позже момента, когда поисковики освоили индексирование динамики, и не видели запроса от SEO на индексируемые динамические сайты, и потому не принимают, что это уже лютое легаси и вынужденный временный костыль.
Я с ужасом жду, когда они повторно изобретут карты сайтов и специализированные шаблоны для поисковиков, которыми обходились до "изобретения" SSR. И будут писать умные книжки, бегать по интернетам и рассказывать, что SSR это очень сложно и дорого и, оказывается, можно обойтись без него. Причём, произойти это должно очень скоро, так как бизнес не дурак и быстро понимает, что SSR это дорого, а плюсов уже практически никаких не приносит.
На самом деле для любителей СЕО есть очень простой вариант - сделать статический дубль сайта на сервере специально для поисковиков. Простые сгенерированные кэшируемые страницы только для ботов и спайдеров. Прекрасно работает и требует минимального времени на разработку.
Поисковики за такое банить должны. Потому что следующим шагом непременно будет разное содержимое у этих страниц и у пользовательских.
Тем не менее именно так индексировался интернет почти 10 лет и до сих именно так индексируется на некоторых тяжёлых сайтах.
А содержимое и так немного разное получается, так как поисковики для индексации используют модифицированные браузерные движки, которые достаточно сильно отличаются от обычных. Ну, и вообще, поисковики честно сползают о своих ботах, в том числе и через API браузера.
И даже SSR на реальных дорогих сайтах даёт довольно сильно отличающееся от видимого пользователем содержимое, так как используется всякого рода закладки вместо поставщиков реальных данных. Совершать по сотне запросов, в том числе на другие сервера, никто в здравом естественно не будет. Подставляют какие-то общие данные и рендерят заглушки.
А так ли нужен SEO сейчас? Есть миллион других способов раскрутки сайтов, приложений
Статья - полная неправда, и противоречит сама себе. SSR сложнее, дороже и не быстрее чем динамические страницы. Зачем и какие реальные плюсы?
Без SSR нельзя сделать маленькую страницу, которая сразу отображать минимальную верстку, а все свистелки и функционал подгружать позже? Можно, и это сильно проще чем городить и поддерживать SSR.
Без SSR нельзя сделать быструю страницу? Очевидно, что можно, и это снова будет проще и дешевле чем SSR.
SSR - гибче и отзывчевей? Муа-ха-ха! Сделайте на нем вёрстку, где DOM (именно DOM, а не стили) зависит от размера/пропорций экрана пользователя и/или наличия тачскрина, и посмотритм, где среди получившихся костылей будут гибкость с отзывчивостью.
Так какую именно задачу решает SSR, чтобы идти на усложнение приложения и инфраструктуры?
Клиентов много, каждый клиент представляет собой независимое вычислительное устройство. Гораздо дешевле поставить дешёвый сервер и переложить весь рендер на клиента тем самым массово и бесплатно распараллеливая обработку.
Во-вторых, при использовании SPA вы практически автоматом получаете и UI и API. Если точное - UI становится просто обёрткой над стандартным API. Не нужно дублировать работу и клиентам максимально удобно интегрироваться.
Последнее - backend становится полностью независимым от UI, может разрабатываться разными командами и на разных языках (в отличие от SSR с гидрацией, который обычно требует одной платформы - node, позволяя делать универсальный код и для сервера и для клиента).
Более того, хорошо написанный фронт будет работать быстро и потреблять мало место (chunk, lazy load, etc...). И полировать и релизить его можно не меняя сервер
У автора с самого начала во главу угла поставлена "веб-страница", а не "веб-приложение". Конечно, как и 20 лет назад, самый логичный путь развития от статической страницы это шаблон статической страницы, слегка модифицируемый на сервере.
рендеринг и прочая херня типа гидротации - это переливаниие из пустого в порожнее. зачем стрjить что-то (типа json), это ведь в чистом виде строка. а потом из строки строить новую строку под названием HTML? ведь можно сразу построить HTML-строку и отдать её клиенту. к примеру серверу на java - "примитивные" jsp-страницы, всё находится в памяти, обращения к диску в основном это обращение к базе (если есть необходимость) так можно сразу строить вычисляемые элементы dom (таблицы, как вариант). исключается куча лишних действий.
если разработчику не хватает мозгов по построению строки HTML, то это проблема руководства этого разработчика, нанявшего такого "знатока".
ssr "медленный", конечно, если рассматривать его как преобразование из одной строки в другую. надо построить одну строку, потом её распарсить, преобразовать и построить уже отдаваемую в виде html.....
"каждому клиенту надо отрисовку делать на сервере. Нагрузка на сервер.".... ага , а построить для каждого клиента json не нужно?
у меня веб-приложения, страницы которых полностью строятся на сервере без рендеринга, и данные выводимые по запросам с этих страниц (таблицы и прочее) также строятся на сервере в виде html, и работает быстро. и на сервер нет нагрузки.
"жухаться" не будет. проверено многократно, что построить json, что построить html для него однорангово
Только к этой "строке", "которая HTML", всё равно нужно прикручивать кучу динамики: таблицы с подгрузкой данных, всплывающие окна, вёрстку, зависящую от устройства пользователя и прочее. Сделать адаптированный под весь спектр устройств сайт без динамики только это бэкэнде это даже не смешно. А как только вы прикручиваете динамику к сайту, то оказывается проще полностью отделить фронт об бэка и перенести форматирование и отображение данных полностью на фронт.
В htmx.org того же мнения, ещё и меньше кода получается в сумме.
Немного не понятен выбор технологий в статье. Есть же SSR frameworks типа next.js например... В практике я пробовал SSR и делали мы это исключительно для SEO, пришлось повозиться и это не так просто, как кажется. В коде появилось куча if-ов, что исполнять на стороне сервера, а что исполнять на стороне клиента, возможно дело было в нашей структуре проекта. В общем, если хочется SSR, лучше подумать 100 раз и сделать статикой, через тот же gatsby, а если нужен backend for frontend (BFF), то SSR это не про это.
архитектура островов — подразумевается, что в море статичного SSR'd HTML есть острова интерактивности.
Виджеты что-ли?)
помню делали нормальные сайты на симфони с серверными twig-шаблонами, и там где по дизайну было много интерактива - выделял div и рисовал в него реактом на клиенте. При чём за счёт порталов можно делать несколько разных таких div-обёрток, и они могли общаться между собой и знать состояние друг-друга.
Оказывается это "архитектура островов"..)))
В статье всё верно описано, одна страница будет работать и грузиться быстрее при сингл пэйдж рендеринге. При использовании фреймворков и теплейт энджинов разработка UI происходит в разы быстрее, где не надо делать каждый компонент с нуля и к нему ещё и рест делать. Что опять же тупо по деньгам на разработку окупается, где лишние пару UI девов будут кушать денег как 20 мощных серверов на года, куда можно запихнуть рендер сервера. В общем если вы не фэйсбук нахрен это не окупается. А потом ещё весь этот зоопарк рест микросервисов поддерживать на бэке, и ещё отдельно поддерживать версии UI, вместо распределенного монолита в кластере как пример.
Про вес странный аргумент довольно странный, учитывая вес любой картинки на сайте. На некоторых сайтах favicon больше весит, чем сам сайт (js бандл)
Зуммеры открыли PHP. О том что SSR нужен был только для поисковиков, потому что они не могли в JS - зуммеры уже даже не в курсе.
Next и Nest - это костыли, которые нужны были для SEO. Они, буквально, создавались, чтобы умереть. Как и создатели Бабеля предполагали что скоро все браузеры будут вечнозелёными и подтфилы устареют.
Знаете, что я вижу в этом посте? Самый настоящий карго-культ. Технологии стали инструментом сегрегации. Будто техно-жрецы из Вархаммер, такие люди развивают и повторяют обряды, вообще не понимая их цели.
Будущее (и прошлое) веба — это рендеринг на стороне сервера