Зачем нужно генерировать одинаковый DOM на фронте и бэке?

Копипастить что? Что я конкретно должен захотеть копипастить?

Шаблоны. Ты будешь кописатить и поддердивать их консистентность/идентичность между SSR и SPA.

Потом оказывается, что данных этих нужно очень много и начинается не-дублирование через GraphQL, чтобы сэмулировать как бы прямой доступ к БД, но как бы немножко ограниченный. В общем, адаптируем проблемы к решениям

Вот поэтому я и говорю, что ты желаешь выкинуть инструменты прослойки, думая, что все может быть проще. Нет — не может.

На сервере обрабатываются не клики, на сервере обрабатывается сжатое промежуточное представление, в которое эти клики засунуты

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

На самом деле в той же Европе

Да не важно где территориально — вебмакаки друг друга найдут, в том числе через ЛОР. А дальше начинается классика — мы упоролись об проблему, которая, в итоге, требует переписать больше половины проекта. Потомучто.

при неободимости часть генерации мы переносим на сервер и даже делаем её однократной

Зачем? Разве хоть кто-то так делает?

Делают и много кто. Если ты вообще понимаешь об чём речь.

Если левая часть (hasOAuthProviders) имеет истинное значение

Истинное значение? «моя мама варит кофе» — это истинное значение или же наглая ложь?

иначе результатом выражения будет ложное значение левой части (обычно false/null/undefined/пустая строка), которые React просто пропускает при рендеринге.

true тоже пропускается при рендеринге. Потому что гладиолус.

Есть небольшая засада — 0 тоже ложное значение в булевом контексте, но его React не пропустит, а отрендерит как есть. Мораль сей басни такова — старайтесь использовать в булевом контексте только булевы значения. Если память подводит — используйте TypeScript, он поможет.

Только если strict=true. Но я бы прежде всего советовал не использовать изначально сломанные инструменты.

это истинное значение или же наглая ложь?

Еще бы не доверять бекенду ))

Истинное значение?

Truthy value (всё, кроме false, null, undefined, 0 и "").

true тоже пропускается при рендеринге. Потому что гладиолус

Никогда не имел с этим ни малейших проблем.

не использовать изначально сломанные инструменты

Когда браузеры начнут поддерживать что-то, кроме JS — будем думать. А пока пользуемся тем, что есть.

А логика view где будет в таком представлении? Например блок с пейджером отображать или не отображать? Или по-разному карточка товара рисуется чуть иначе если есть видео с товаром или только картинки

и даже это не проблема, пишем перед проверкой предварительно:

typeof myVar === 'boolean'

и делов.

Еще раз — он пока до этого не домыслил )) Вот щас общую картину в голове построит, тогда и за нюансы сам думать начнет — чай не дурак.

Кажется речь о рукожопии.

В шаблонизаторах обычно и условные операторы бывают. Что-нить типа «если эта переменная пустая/отсутствует то текст такой, если не пустая то такой». Делать ли просто большой if-else вокруг двух вариантов карточки целиком, или же засовывать под этот if отдельные её части - на выбор верстальщика, в зависимости от того что он хочет нарисовать.

Неа ))

Гораздо эффективнее отдать горячий кеш подготовленных шаблонов, чем перегенеривать их на каждый чих.

Гораздо эффективнее отдать закешированные данные о наличии остатков товаров, а не ходить в базу и узнавать, сколько их там реально осталось. Речь, конечно, о кейсах, когда за наличием товара с ID = X ломятся каждые N милли (а может и микро) - секунд. И пусть лучше в момент заказа товара клиент увидит реальный ответ бекенда «ничо не осталось, купить нельзя».

Какие тут рукожопия?

общую картину в голове построит

Судя по данным подозрениям, фантазируешь на ходу тут видимо ты, но не надо думать что остальные занимаются тем же. Я всего лишь пишу как на деле происходит в нормальных местах, все вопросы рассмотрены и отвечены задолго до этой беседы.

У меня тоже все заранее реальным опытом подтверждено. Очень может быть, что мои знания немного устарели. Но они устарели инструментально, а не базово. Так что не гони.

Ну и да — я попутал тебя с ТС.

И каким это боком к отрендеренной на клиенте странице?

Тем более, что жс тебе на клиенте всё рисует и серверу пофиг что отдавать.

И каким это боком к отрендеренной на клиенте странице?

Да прямым — чем быстрее оно отрендерится, тем лучше. А уж какими горячими кешпми это реализуется — вопрос реализации.

жс тебе на клиенте всё рисует и серверу пофиг что отдавать

Но жеесу может быть не пофиг, когда надо нарисовать горячий кеш остатков через SSR, а не JSON. Ты же, в дикой природе, только по месту узнаешь, в каком виде и каким образом бекенд что-то там отдает.

Погоди, ты либо хочешь чтобы страница появилась сразу, а значит рисуешь всё на сервере. Либо тебе пофиг и рисуешь жсом.

То что ты сбегаешь в базу или нет решаетмся кешом приложения, которое тот же жсон может из кеша отдать.

Да вообще плевать. Я говорю о том, что не важно какие прослойки логики и как они в итоге рисуют, важнее тут, что способов кеширования и отрисовки «тыща и одна тележка».

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

Кокого «динамического контента»? Ну типа по классике жанра какие-то сообщения аля «микроблогинг с картинками» — это очевидно статичный контент после его создания, его не нужно рендерить на клиенте. Потому я и пишу, что я не знаю годного примера. Большинство примеров SSR — это просто неадекваты сделали на 90% статичный сайт на React.js и теперь им нужна SEO оптимизация.

Соответственно, об этом и был исходный вопрос: если контент форматируется на сервере, то зачем его перерисовывать на клиенте? Если контент динамически создаёт клиент, то на сервере этой логике нечего делать. И ниже по треду был пример Figma, которая вообще использует третью логику на C/C++ для отрисовки контента — это почти годный пример, но неплохо было бы найти хотя бы второй.

Так что по сути ответ на вопрос: нужно отдавать HTML с бекенда, для чего переиспользуем код фронтенда.

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

Что поделаешь, в JS (и во многих других популярных языках) выражение вычисляется в какое-то одно значение. Если тебе нужно получить из выражения несколько значений — ты должен обернуть их в какую-то структуру данных, например, массив.
Когда браузеры начнут поддерживать что-то, кроме JS — будем думать. А пока пользуемся тем, что есть.

Но JSX — это не JS, ололо, браузеры не могут интерпретировать JSX. Никто не заставлял их делать такой омерзительный язык шаблонов.

Шаблон как шаблон. Чем это принципиально отличается от какого-нибудь JSP?

К сожалению, не знаком с JSP, так что воздержусь от комментариев.

JSX — это просто тонкий слой сахарка над выражениями нижележащего языка (JS, ReScript, что угодно).

Не совсем. В ReScript JSX реально поправили, речь идёт про JSX-подобный диалект. Например, в ReScript атрибуты и дочерние выражения не обязательно оборачивать в фигурные скобки. Что if-else является функцией — это да, это уже фича ReScript.

В JS if/switch — это не выражение и не возвращает значения, поэтому его нельзя использовать вместо тернарного оператора, не изобретая специально для JSX новый синтаксис языка или новую семантику для старого синтаксиса — но тогда слой сахарка становится гораздо толще.

Но во Vue же изобрели? Значит им можно?

Если бекэнд, вместо того чтобы отдать блоб с текстовыми подстановками, будет каждый раз его генерировать их отдельных dom-нод вручную - ничего, кроме дополнительного жора проца, он от этого не получит

Если дебил будет зажигать зажигалку каждые 10 секунд, то зажигалка очень быстро кончится.

Для большинства типовых обработчиков стоимость запросов к базам намного дороже, чем стоимость всех этих ваших VDOM и шаблонизаторов. Так что я не совсем понимаю, о чём вы тут между собой и со мной спорите.

Разумеется, всегда будет какое-то количество кода, специфичного для конкретного окружения, который в других окружениях не пригодится. И что? Общая кодовая база, содержащая неспецифичный код, всё ещё может принести немало пользы.

Может. А может и не быть. Об этом и вопрос. Из того, что я видел на форумах — всё это сводится к общим декларациям структур данных для JSON-а, за счёт чего бэк намертво приклеивается к фронту и ошибка в формате данных от клиента валит сервер — такое-себе «преимущество».

Так ты сейчас критикуешь конкретно React — далеко не самую удачную реализацию фронтендного компонентного фреймворка. Сравнить хотя бы с тем же SolidJS. Там JSX не перемешан ни с циклами .map, ни с условиями в виде && или тернарников.

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

Но, да, пример хороший, почему-то в SolidJS оставили тернарники и ввели более адекватные явные конструкции:

<Show when={loggedIn()} fallback={<button>Log In</button>}>
  <p>Welcome back, user!</p>
</Show>

Тем не менее, даже такая радость на самом деле не нужна для шаблонов на сервере — это реально оптимизации для клиентских шаблонов, не серверных. Какая в принципе может быть реактивность на сервере? Никакой, все значения статичны.

Нужно хорошее SEO - лучше чтобы бекенд отдавал статику и минимум рисовалось JS. Это улучшает метрики открытия страницы, которые влияют на поведенческие факторы.

Я даже предупредил, что вопрос сложный.

Чтобы бэкенд отдавал статику, нужно сделать бэкенд, который будет отдавать статику. Всё, никакого переиспользования JS не нужно.

Шаблоны. Ты будешь кописатить и поддердивать их консистентность/идентичность между SSR и SPA.

Давай начнём с исправления некорректной терминологии — клиентская часть SSR называется CRS, а SPA и SSR взаимно противоречащи.

Далее, проблема повторного рендеринга серверных шаблонов на клиенте стоит только если мы хотим сделать изначально статичный контент динамичным. Отсюда вопрос — какой изначально статичный контент мы должны хотеть резко сделать динамичным на клиенте?

Вот поэтому я и говорю, что ты желаешь выкинуть инструменты прослойки, думая, что все может быть проще. Нет — не может.

Если уж на то пошло, то ты не совсем угадал — я скорее намекаю на то, что эта самая прослойка не так уж магически решает все проблемы, и скорее создаёт их столько же, сколько решает.

И еще раз — это и есть те самые адаптеры/прослойкм, которые скрывают для тебя нюансы реализации чего-бы то ни было и предоставляют чистый интерфейс для бизнес-задач как на фронте, так и на бекенде.

Это не «адаптеры-прослойки», в случае логеров это вполне явный клиент-серверный алгоритм с самым что ни на есть чётким разделением обязанностей, ничего серверного нет на клиенте, ничего клиентского нет на сервере.

Зачем? Разве хоть кто-то так делает?

Делают и много кто. Если ты вообще понимаешь об чём речь.

Это забавно, что чел, который не в курсе регресса нынешнего сайтостроения (Зачем нужно генерировать одинаковый DOM на фронте и бэке? (комментарий)), даже не понимает, в чём проблема.

У меня, на самом деле, вопрос похожий, с той лишь разницей, что я-то как раз хорошо понимаю, как оно нынче делаются в индус-трии:

Зачем нужно генерировать одинаковый DOM на фронте и бэке? (комментарий)

какой изначально статичный контент мы должны хотеть резко сделать динамичным на клиенте?

Зачем нужно генерировать одинаковый DOM на фронте и бэке? (комментарий)

Из того, что я видел на форумах — всё это сводится к общим декларациям структур данных для JSON-а, за счёт чего бэк намертво приклеивается к фронту и ошибка в формате данных от клиента валит сервер — такое-себе «преимущество».

Зачем нужно генерировать одинаковый DOM на фронте и бэке? (комментарий)

Кокого «динамического контента»? Ну типа по классике жанра какие-то сообщения аля «микроблогинг с картинками» — это очевидно статичный контент после его создания, его не нужно рендерить на клиенте.

Зачем нужно генерировать одинаковый DOM на фронте и бэке? (комментарий)

А логика view где будет в таком представлении? Например блок с пейджером отображать или не отображать? Или по-разному карточка товара рисуется чуть иначе если есть видео с товаром или только картинки

На этой задаче многие SSR обсираются конкретно, на самом деле. У них серверная статика показывает одно, клиентская динамика выкидывает половину этого в мусорник и переделывает всё по своему.

Судя по данным подозрениям, фантазируешь на ходу тут видимо ты, но не надо думать что остальные занимаются тем же. Я всего лишь пишу как на деле происходит в нормальных местах, все вопросы рассмотрены и отвечены задолго до этой беседы.

Если ты когда-нибудь заходил на всякие там интернет-барахолки (если не заходил — лучше не делай этого), то ты мог видеть, что там есть картинка с товаром, там есть описание текстово-картиночное, но картинки можно перебирать, аля слайд-шоу, а ещё есть видео вместо картинок, а еще бывает видео в описании. То есть, типовой такой смешанный контент, в голом HTML+CSS ты этого не сделаешь (хотя это спорно, при использовании :target можно переключать блоки картинок).

И вот вопрос стоит в том, как же это всё дело реализовать, кто будет описывать скрипты, кто какую часть логики у себя будет выполнять. Ты можешь подставить URL видео в HTML шаблон, но к нему нужны какие-то элементы управления.

Вы вместо того, чтобы найти общий язык, начали тут цирк устраивать. По этой причине я в последнее время задаю вопросы нейросетке, а не форумам. Сколько я задавал промты — мне чатгпт никогда не отвечала в духе: «Ты пока не домыслил. Подождём, пока ты общую картину в голове выстроишь и за ньюнсы начнёшь думать».

Гораздо эффективнее отдать горячий кеш подготовленных шаблонов, чем перегенеривать их на каждый чих.

Внезапное возражение с ноги: оптимизированные SPA могут грузиться очень быстро и запрашивать кэшируемые JSON-ы с сервера. Многие SPA так долго грузятся только потому, что пытаются с первого открытия загрузить все вкладки со всеми функциями.

(А, ну да, уже ответили Зачем нужно генерировать одинаковый DOM на фронте и бэке? (комментарий)
То что ты сбегаешь в базу или нет решаетмся кешом приложения, которое тот же жсон может из кеша отдать.
)

Потому на самом деле статичный HTML нужен для SEO и дружелюбности к ботам. Не то, чтобы я был большим фанатом HTML и звал всех срочно бросать JS — скорее я всё-таки хейтер JavaScript. Ну то есть из варантов «отрендерить шаблон темплейтером в HTML» и «отрендерить JSON в DOM через JavaScript» я выберу темплейтер с HTML.

А что тут спорного? Ну написано чуток коряво, а тернарники такой вложенности обычно правилом линтера запрещены.

если контент форматируется на сервере, то зачем его перерисовывать на клиенте?

Если незачем, то и не нужно.

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

Это и не задача заказчика решать что будет оптимально, а что нет.

А что тут спорного? Ну написано чуток коряво, а тернарники такой вложенности обычно правилом линтера запрещены.

Я думал сразу развернуть тему, но решил, что сначала подожду ответов.

Проблема в том, что вся выстроенная на базе JSX модель — говно дерьма, одно из проявлений которого — убогий язык шаблонов, но на самом деле проблем больше. Например, проблема различной обработки малой динамичности, большой динамичности, и полной статики — реактовые шаблоны мешают всё в кучу, даже не пытаясь ничего исправить спустя 13 лет. И потому
Зачем нужно генерировать одинаковый DOM на фронте и бэке? (комментарий)

Очень просто на js сразу в браузере отрендерить всю страницу целиком, а не заниматься какой-то конвертацией js -> html -> браузер

на самом деле не очень и не просто. Ну то есть это может быть просто только из позиции того, что у нас точка отсчёта — это «вся система сделана на React.js», но с какого перепуга это точка отсчёта? Написать статичную страничку на голом HTML проще, чем лепить деревья на React.createElement, и даже JSX всё равно сложнее получается.

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

Нет. Солид единократно исполняет функции, заданные в JSX-шаблоне, а затем работает с компонентами по реактивному принципу через сигналы. То есть он прямо сразу за основе зависимостей данных может определить, какой именно DOM-элемент ему нужно менять. В Реакте JSX-шаблоны пересчитываются каждый раз при любом изменении данных, каждый раз формируя новое виртуальное дерево. Далее ему необходимо сравнить это новое дерево со старым, чтобы определить, какие из DOM-элементов менять.

Поэтому в Реакте в шаблонах можно использовать операции JS — они пересчитываются каждый раз, а в Солиде это не сработает правильно.

проблема различной обработки малой динамичности, большой динамичности, и полной статики — реактовые шаблоны мешают всё в кучу, даже не пытаясь ничего исправить

Нужно ли их разделять? Jsx достаточно шустрый, если оптимизировать, а не пересчитывать все на каждый чих.

Ну то есть это может быть просто только из позиции того, что у нас точка отсчёта — это «вся система сделана на React.js», но с какого перепуга это точка отсчёта?

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

Нет. Солид единократно исполняет функции, заданные в JSX-шаблоне, а затем работает с компонентами по реактивному принципу через сигналы.

Нет да. Например, в примере https://www.solidjs.com/examples/context меняю заголовок на

{ theme.title ? (<h1
  style={{
    color: theme.color,
  }}
>
  {theme.title}
</h1>) : (<h2 />)}

_$memo((() => {
    const _c$ = _$memo(() => !!theme.title);
    return () => _c$() ? (() => {
      const _el$3 = _tmpl$3();
      _$insert(_el$3, () => theme.title);
      _$effect(() => theme.color != null ? _el$3.style.setProperty("color", theme.color) : _el$3.style.removeProperty("color"));
      return _el$3;
    })() : _tmpl$4();
  })())

В этом и суть, что граф данных сам однозначно определит, когда нужно рисовать элемент, а когда нет. В Реакте для этого закостылено промежуточное представление дерева.

Нужно ли их разделять? Jsx достаточно шустрый, если оптимизировать, а не пересчитывать все на каждый чих.

Ну так а я тебе о чём? В чём заключается оптимизация? В том, что ты разделяешь статику, малую динамику, и динамику, чтобы не пересчитывать всё дерево на каждый hover.

Это просто удобно. У тебя уже есть фронтэндеры, какие-то наработки с других проектов, готовые либы и компоненты.

В принципе, это удобно, если у тебя есть реакт-фронтендеры по цене грязи. Однако, уже после 2022 эта проблема стала неактуальна, фронтендеров в 10 раз больше, чем работы для них, потому аргументация «работаем с тем, что поймали» больше не работает.

В этом и суть, что граф данных сам однозначно определит, когда нужно рисовать элемент, а когда нет. В Реакте для этого закостылено промежуточное представление дерева.

Я тебе о том, что SolidJS на каждое изменение !!theme.title делает гарантированное изменение DOM. Гарантированное! Никаких дифов, никаких обновлений свойств, только удаление старого узла и добавление новосозданного.

Из-за этого в циклах во Vue и SolidJS используются ключи — ихние рантаймы создают удаляют дочерние элементы по ключам, а не по VDOM.

А что ему ещё остаётся, если я и говорю, что тернарник не будет работать как задумано. Там <Show> нужен, который не будет пересоздавать элемент.

Из-за этого в циклах во Vue и SolidJS используются ключи

Ключи и в React нужны. Они нужны и в Svelte. Как иначе определить соответствие DOM-элемента (или VDOM-элемента) элементу итерируемого массива? К слову, Vue тоже использует VDOM под капотом.

бэк намертво приклеивается к фронту и ошибка в формате данных от клиента валит сервер

Как Страшно Жыть :)

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

Можно, конечно, возложить исправление сломанного на того, кто это сломал — но это, вообще говоря, требует от всех разработчиков разбираться и в бэке, и в фронте. Поделиться на кучки по принципу бэк/фронт уже не получится.

То есть, по сути, общая кодовая база предъявляет повышенные требования к квалификации разработчиков.

о чём вы тут между собой и со мной спорите

Мы просто увидели, что у собрата-обезьяна пригорает, и пришли успокаивать. Ну как умеем.

Минусы у общей кодовой базы, конечно, тоже есть — скажем, поменяли на бэке общее определение типа данных для какой-то сущности

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

Намного веселее когда у нас на бэке крутится ровно такой же жаваскрипт, но без браузера, который рендерит те же странички и там, и тут, иногда они получаются одинаковыми, иногда — нет. Это то, о чём был изначальный вопрос: зачем кому-то может понадобиться рендерить тот же DOM на сервер и клиенте одновременно?

Мы просто увидели, что у собрата-обезьяна пригорает, и пришли успокаивать. Ну как умеем.

Исходный вопрос был вообще не про производительность — я ни одного слова про производительность не написал. Вопрос вообще не стоит о том, быстро ли нода выполняется или медленно, вопрос в том, зачем мне в принципе нода на сервере нужна? Хоть быстрая, хоть медленная.

иногда они получаются одинаковыми, иногда — нет.

В норме они должны быть одинаковыми.

зачем кому-то может понадобиться рендерить тот же DOM на сервер и клиенте одновременно?

Если фронтенд работает на фреймворке и есть необходимость прогрузить разметку с сервера заранее: для поисковиков или чтобы улучшить метрику First Contentful Paint.

зачем мне в принципе нода на сервере нужна?

Либо для SSR, либо если бекенд на ноде написан.

зачем мне в принципе нода на сервере нужна?

Что бы динамический сайт отдать статично для поисковиков.

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

Это не решение, это вынужденная мера в командах, где бек и фронт разработчики разделены на разные команды. Называется закон Конвея

Это то, о чём был изначальный вопрос: зачем кому-то может понадобиться рендерить тот же DOM на сервер и клиенте одновременно?

Потому что тебе нужно уметь отдать статическую страничку, а потом по ней ходить динамическим кодом.

Я не предлагал «голый html+css». Я писал про то что незачем на сервере оперировать понятиями dom-нод - ему они вообще ни с какого боку не нужны. Что касается пролистывания картинок, то тут два варианта:

1) Если картинок немного то лучше всего их всех сразу отдать в html (только с display:none), а в браузерном джаваскрипте по нажатию кнопок переключать им стили чтобы показывалась нужная.

2) Если много - клиентский джаваскрипт будет делать ajax-запросы чтобы узнать очередную каритнку или их пачку. Да, в этом случае разумнее делать сборку dom этим же джаваскриптом из json-ов, а не слать предподготовленный html с сервера. Но на сервере этот dom всё так же не нужен: сервер шлёт браузеру json с данными, скрипт в браузере собирает dom. Если тебя смущает, что при статической отдаче мы тупо шлём готовый html-шаблон, а при динамической - собираем dom, ну, прими что это норм, верстальщику придётся поработать чуточку больше (и html-шаблон написать, и заскриптовать рисование того же самого для динамических случаев), зато результат получится во всех отношениях лучше, чем не пойми зачем возня с dom-ом на сервере.

Я писал про то что незачем на сервере оперировать понятиями dom-нод - ему они вообще ни с какого боку не нужны.

А тебе отвечали, что половина всего интернета генерирует DOM ноды на серверах. Нравится тебе это или нет.

Если картинок немного то лучше всего их всех сразу отдать в html (только с display:none), а в браузерном джаваскрипте по нажатию кнопок переключать им стили чтобы показывалась нужная.

Кнопка увеличения картинки. Автоматическое слайдшоу. «А если картинок очень много». Я могу придумать кучу сценариев, ты всегда должен понимать, что «создать вебсайт» — это задача неограниченной сложности, весь интернет не сводится к одному интернет-магазину.

2... Если тебя смущает, что при статической отдаче мы тупо шлём готовый html-шаблон, а при динамической - собираем dom, ну, прими что это норм, верстальщику придётся поработать чуточку больше (и html-шаблон написать, и заскриптовать рисование того же самого для динамических случаев)

Меня смущает то, что для одной страницы мы делаем разную вёрстку и руками пытаемся её свести так, чтобы она совпадала. Есть сайты, которые вылизывают годами, но большинство это не устраивает, и я могу их понять. Зачем делать работу, которую можно не делать? Тем более, что в 2025 работа айтишника намного дороже работы компьютера.

А тебе отвечали, что половина всего интернета генерирует DOM ноды на серверах. Нравится тебе это или нет.

А я напомню, что в этой теме ты спрашивал зачем генерить dom в том числе и на сервере. Я тебе отвечал - низачем. От того что половина веб-макак этим занимается, ситуация не меняется. Они вообще очень часто занимаются ненужными вещами.

Кнопка увеличения картинки.

<img src="..." data-id="...«> и в скрипте по data-id создаём увеличенную картинку.

Автоматическое слайдшоу.

Не вижу проблем.

Меня смущает то, что для одной страницы мы делаем разную вёрстку и руками пытаемся её свести так, чтобы она совпадала.

Ну, зря смущает.

Есть сайты, которые вылизывают годами, но большинство это не устраивает,

Не вылизывай, делай помои, кто ж тебе запретит. Способов сделать помои очень много, выбирай любой.

Тем более, что в 2025 работа айтишника намного дороже работы компьютера.

Только сравнивать надо 5 минут работы верстальщика и годы потраченного cpu-time.

В крайнем случае можно использовать какой-то визуальный редактор который тебе и html сделает и js-генератор для dom сразу из общего источника. Но работать оно должно на компе автора вёрстки один раз, а вовсе не на сервере при каждом запросе.

Только сравнивать надо 5 минут работы верстальщика и годы потраченного cpu-time.

Годы потраченного CPU не вернуть.

В остальном по большей части согласен. Также мне понятно, почему меня с тобой спутали (хотя макском давно добавил тэг автора топика).

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