Какой дурак использует фреймворки?

Я имел ввиду, если бэкенд совсем-совсем чужой :-) И на него повлиять нет возможности.

А какая альтернатива? Императивно жикверить DOM?

Меня иногда такая крамольная мысль посещает

function _setup(el, attrs, events) {

	if (!el)
		return '';

	switch (typeof el) {
		case 'string':
			el = document.createElement(el);
		case 'object':
			for (const key in attrs) {
				attrs[key] === undefined ? el.removeAttribute(key) :
				key === 'html' ? el.innerHTML   = attrs[key] :
				key === 'text' ? el.textContent = attrs[key] :
				key in el    && (el[key]        = attrs[key] ) == attrs[key]
							 &&  el[key]       == attrs[key] || el.setAttribute(key, attrs[key]);
			}
			for (const name in events) {
				if (!events[name])
					continue;
				if (Array.isArray(events[name]))
					events[name].forEach(handler => el.addEventListener(name, handler, false));
				else
					el.addEventListener(name, events[name], false);
			}
	}
	return el;
}

Просто нарисовал дерево компонентов, и реактофиксики его собрали в готовый DOM

Но есть же нормальный PHP. Если не нравится сам язык (как мне) есть же EJS.

Понял вас. Тогда - это печально.

function _setup(el, attrs, events) {

Если надо один раз настроить компонент и забыть, то нормально. А если attrs/events изменятся, надо будет снова _setup вызывать? А если у нашего компонента есть дочерние компоненты — их ведь тоже надо как-то отрисовывать/перерисовывать?

То есть всё равно там некая имитация браузерной DOM-модели, написанная на JS, дабы выполнить все эти скрипты и выплюнуть HTML.

По сути, да.

Это по определению будет тяжелее, чем выполнить специально подготовленный код, возвращающий HTML без промежуточной манипуляции с DOM.

А вот это вопрос спорный по двум моментам:

1. Если на бекэнде будем заморачиваться генерацией не только json, но и html, то это доп.нагрузка на программистов, проект получается дороже.
2. JS довольно быстрый язык программирования, например, по сравнению с питоном. И он гораздо быстрее, чем шаблонизаторы, написанные на питоне. Тормоза при генерации html страницы не очень большие.

если пристально не вглядываться в папку node_modules

Классики не рекомендуют пристально вглядываться в такие вещи.

Если на бекэнде будем заморачиваться генерацией не только json, но и html, то это доп.нагрузка на программистов, проект получается дороже.

В том и прикол, что если фронтенд сразу пишется на базе изоморфного фреймворка (например, для React это Next.js), то получение HTML практически бесплатно — это сам фреймворк обеспечивает.

JS довольно быстрый язык программирования, например, по сравнению с питоном. И он гораздо быстрее, чем шаблонизаторы, написанные на питоне.

Вот именно. Бекендеры на питоне будут продолжать отдавать свои джсоны, а рендеринг в HTML будет через JS.

А если attrs/events изменятся, надо будет снова _setup вызывать?

Проще непосредственно в DOM.

А если у нашего компонента есть дочерние компоненты — их ведь тоже надо как-то отрисовывать/перерисовывать?

Да, но это утрированный пример. Конкретно эта функция из lorify-ng, она годится только для таких простых приложений.

А по-нормальному, если надо поменять данные, то пользователь отправляет новый HTTP-запрос и сервер ему генерирует новую страницу. Если надо по мере того как пользователь печатает обновлять текст в textarea, то ничего не надо делать, оно так и есть в HTML.

Есть еще такая дебильная штука Redux. Чтобы хранить состояние приложения, достаточно сделать объект со свойствами, часть из которых функции, просто singleton. Я же вместо обычного вызова функции должен везде писать вот такую балду store.dispatch({ type: SET_FEEDBACK_COUNT, feedbackCount: msgNum });. И еще надо поддерживать кучу кода, где все эти константы объявлены, где создается этот store и т.д..

Всё вроде бы и ничего если пристально не вглядываться в папку node_modules.

Т.е. вглядываться в мамку?

Так используйте не redux, а mobx или какое-либо другое решение.

Т.е. вглядываться в мамку?

Можете вглядываться, можете от Обезьяна привет передать, ваша мама, вам решать.

если надо поменять данные, то пользователь отправляет новый HTTP-запрос и сервер ему генерирует новую страницу.

Поставил клоуна — ннна получай новую страницу %)

дебильная штука Redux. Чтобы хранить состояние приложения, достаточно сделать объект со свойствами

Это всё работает до тех пор, пока один и тот же кусок состояния не начинают щупать несколько компонентов сразу и ты не перестаёшь понимать, кто, когда и почему его изменил. Асинхронщина + неконтролируемые изменения === ужос и боль.

Когда всё состояние хранится централизованно и изменяется тоже централизованно, понимать, что происходит, становится гораааздо проще — достаточно глянуть в историю изменений.

У Redux, конечно, API своеобразный (особенно для тех, кто ещё до функциональщины не добрался), но есть же аналоги. В 18м реакте вообще есть встроенный хук useReducer, который делает примерно то же самое.

Смысл sql - в декларативном подходе

Прям поспорил бы.

Если вы императивно в явном виде не поможете планировщику с выбором партиции (там где это возможно) - декларативно он будет тупо все партиции перебирать.

Больше того - ПГ не сможет угадать партицию, если вы будете делать JOIN по полям запрошенной таблицы, а не по явно заданным значениям.

А в ClickHouse, например, если вы императивно не поможете своему JOIN'у повтором условия в WHERE - получите в два раза дольше время исполнения.

Декларативность она где-то в докерах на пяти таблицах по сотне записей.

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

Какие-нибудь Гуру БД и вас, и меня сожрут с потрохами еще более удивительными примерами.

Зачем вас есть если вы в целом все верно пишите?

Вот именно. Бекендеры на питоне будут продолжать отдавать свои джсоны, а рендеринг в HTML будет через JS.

Давайте все-таки признаем - не было бы тупого желания поисковиков одним GET-запросом сразу получать нужную им текстуху, не появилось бы и никакого SSR :) Отсюда и «неестественность» SSR. Ну и пускать на бэкенд фронтенд-разработчиков, привыкших к тому, что их код выполняется на стороне клиента и можно издеваться над процессором и памятью как угодно - это шаг еще тот…

Честно говоря, когда гуглы на весь мир протрубили, что они скоро начнут полноценно краулить фронтенд-приложения, мне было очень любопытно, как они потом будут выкручиваться из этого заведомо провального мероприятия. И это было явным звоночком, что и в корпорации Google ну очень существенно деградировал в умственном плане слой «эффективных манагеров» )). Кстати, вслед за ними о тех же намерениях, хоть и более осторожно, но заявили и остальные поисковики - проявили, так сказать, свою стадную сущность))

не было бы тупого желания поисковиков одним GET-запросом сразу получать нужную им текстуху, не появилось бы и никакого SSR :)

А как же нетерпеливые пользователи, first contentful paint и всё такое. Размер бандла опять же. Опасения за чувствительную информацию типа токенов на клиенте.

… first contentful paint

Пользователю комфортнее быстро увидеть шаблон страницы с колесиком ожидания, что быстро обеспечивается без всякого SSR, чем наблюдать секунду-другую белое окошко в ожидании «first contentful paint». Это скорее хотелки поисковиков.

Размер бандла опять же

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

Опасения за чувствительную информацию типа токенов на клиенте.

А вот это я не понял, каким боком относится к SSR. Использования токенов на клиенте вам не избежать в любом случае. Иначе как вы будете поддерживать аутентификацию при последующих API-запросах?

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

Откуда вдруг появится колёсико до загрузки клиентского бандла, если не отрисовать его на сервере?

Размер бандла при SSR не меньше

Кот, который выполняется только на сервере, в клиентский бандл класть не обязательно.

каким боком относится к SSR. Использования токенов на клиенте вам не избежать в любом случае

Если какие-то данные отрисовываются только на сервере, клиенту за ними ходить не нужно же, и токен ему не нужен.

Откуда вдруг появится колёсико до загрузки клиентского бандла, если не отрисовать его на сервере?

Так у вас же фронтенд-приложение и мы обсуждаем случай отсутствия SSR. Сразу после загрузки начальной index.html-странички по HTTP2 подтягивается начальный javascript + css + плюс это колесико :) - в Vue это можно уложить где-то в ~200к. Вот этот код и отрисует очень быстро начальный шаблон и колесико. При использовании SSR на стороне сервера придется выполнить дополнительные API-запросы. Так что, время отдачи начальной HTML-ки будет не быстрее.

Кот, который выполняется только на сервере, в клиентский бандл класть не обязательно.

В плане размера загружаемого для PWS бандла SSR не дает никакого выигрыша в размере. Тот же Vue-движок вам придется грузить на клиент в любом случае. И отрисовывать начальную страницу повторно придется и на клиенте. При отсутствии SSR ничего из фронта не выполняется на сервере - Nginx только отдает index.html и прочие ассет-файлы - все начинает быстро раскручиваться на клиенте.

Если какие-то данные отрисовываются только на сервере, клиенту за ними ходить не нужно же, и токен ему не нужен.

То, что отрисовывается при первом заходе на сайт, не предполагает использования каких-либо токенов на стороне сервера - независимо от того, используется ли SSR или нет. Для получение токена пользователь должен выполнить процедуру аутентификации - типа, получить какой-нибудь временный код по SMS или email. И хранится этот токен далее будет на клиенте.

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

А когда вы на бекенде крутите Хром, в котором запускаете фронтендный скрипт, он выполняется на стороне конечного клиента или на сервере? Так что SSR эффективнее хотя бы тем, что убирает ненужный слой парсинга HTML, DOM, CSS и последующего обратного преобразования в строку. Я уже не говорю о том, что в SSR можно отдавать страницу потоком, пока ещё даже не пришли все ответы на запросы.

А когда вы на бекенде крутите Хром …

Хром крутится только для запросов поисковых роботов, а SSR - для всех пользователей. Не забывайте про это, когда пытаетесь сравнивать.

Я уже не говорю о том, что в SSR можно отдавать страницу потоком, пока ещё даже не пришли все ответы на запросы

Ну это все из области фантазий. Если у вас есть, к примеру, на странице лента соц-сети, то вы и при SSR должны сначала получить по API первую порцию данных ленты - и только потом начать выдачу HTML клиенту. А вот без SSR можно просто сразу нарисовать колёсико :) а потом подтянуть данные

Хром крутится только для запросов поисковых роботов, а SSR - для всех пользователей. Не забывайте про это, когда пытаетесь сравнивать.

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

Ну это все из области фантазий. Если у вас есть, к примеру, на странице лента соц-сети, то вы и при SSR должны сначала получить по API первую порцию данных ленты - и только потом начать выдачу HTML клиенту.

Так в том и прикол потоков, что нет. Можно начать отдавать статическую часть шаблона, которая содержит теги html, head, meta, link, script ещё до того, как придут данные для отрисовки body. Это резко сокращает TTFB. Заодно браузер уже сможет подгрузить и проинициализировать стили и скрипты.

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

Так набирайте не из основной массы, а из тех, кто имеет представление. QA-специалисты у вас есть, чтобы нагрузочное тестирование проводить?

Так в том и прикол потоков, что нет. Можно начать отдавать статическую часть шаблона, которая содержит теги html, head, meta, link, script ещё до того, как придут данные для отрисовки body. Это резко сокращает TTFB.

И что вам отрисует веб-обозреватель? Шапочку странички? В чем выигрыш по сравнению с вариантом без SSR если игнорировать интересы поисковиков?

Так набирайте не из основной массы, а из тех, кто имеет представление

В той микрокоманде, которую я сейчас поддерживаю - фронтенд из Яндекса)

И что вам отрисует веб-обозреватель?

отрисует фон

В чем выигрыш по сравнению с вариантом без SSR если игнорировать интересы поисковиков?

Без SSR — никакой

«Фронтенд из Яндекса» — не показатель его уровня.

Однако и он может сделать фронтенд. А вы — нет )

Во-вторых, если у вас есть кеширование на выходе, то скорее всего либо кеш предварительно прогрет, либо его прогрел поисковик, либо предыдущие пользователи. Так что нагрузка на сервер всё равно не должна быть большой.

Я имею дело с приложениями, где какое-либо кеширование HTML противопоказано - всегда надо предоставлять текущее актуальное состояние данных. Ну PWA же…

И что дальше?) Это ответ в стиле «сам дурак»?))

Я имею дело с приложениями, где какое-либо кеширование HTML противопоказано

Вот тогда отдача SSR потоком будет эффективнее по метрике TTFB, чем ждать полного рендеринга

всегда надо предоставлять текущее актуальное состояние данных

А выше вы говорили, что чистите кеш раз в сутки. Снова себе противоречите?

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

А выше вы говорили, что чистите кеш раз в сутки. Снова себе противоречите?

Вы невнимательно читаете - я чищу кеш веб-обозревателя от неактуальных ассет-файлов (js, css, и пр). Index.html вообще не кешируется, поскольку это один фиксированный файл для все URL-к, который меняется только при смене версий фронта

когда ответить по существу нечего, то начинается вот такое… ) Я и не претендую на роль фронтенд-программиста, хотя с DOM знаком. Я просто пытаюсь донести все «ЗА» и «ПРОТИВ» для каждого из вариантов решения SEO-проблемы.

Разве вы изложили все «ЗА» варианта SSR? Вы изначально сказали, что не считаете его приемлемым без подробного обоснования. Теперь же оказывается, что это мне по существу сказать нечего. Фронтендеры у вас якобы все поголовно пишут неэффективный говнокод, который нельзя пускать на сервере, поэтому вы его пускаете на сервере, а для пущей «эффективности» — в целом браузере. Во фронтенде тоже не разбираетесь, но задачу об установке «флажка» сами оценили как простую. И это после того, как пытались сначала убедить аудиторию в «абсолютной независимости» фронтенда для вашего решения. Когда речь заходит о SEO-метриках, вы внезапно передёргиваете на варианты без учёта SEO.

Разве вы изложили все «ЗА» варианта SSR?

Ну, для этого в теме присутствуют другие. Например, вы )

… поэтому вы его пускаете на сервере, а для пущей «эффективности» — в целом браузере…

На это я уже ответил - не хочу повторяться. Вы, похоже, слишком эмоционально восприняли мои посты и слегка утратили способность внимательно и адекватно воспринимать мои ответы - take it easy)

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

Тем не менее, многие в мире и по сей день почему-то делают выбор в пользу пререндеринга. Польза этой темы в том, что все сюда заглянувшие теперь знают о двух вариантах решения проблемы. Решать, что больше подходит - им самим.

почему-то

А вы можете объяснить почему?

А вы можете объяснить почему?

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

А как они решили проблему гугла?

А как они решили проблему гугла?

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

Вы вообще воспринимаете осмысленно мои ответы?)

Я говорю не о клиентах сервиса, а о самом сервисе prerender.io. Они тоже просят флажок готовности?

Я говорю не о клиентах сервиса, а о самом сервисе prerender.io. Они тоже просят флажок готовности?

Там есть несколько вариантов - в том числе и по флажку, как самый надежный. Почитайте интерфейс сервиса.

https://docs.prerender.io/docs/11-best-practices

Так у вас же фронтенд-приложение и мы обсуждаем случай отсутствия SSR. Сразу после загрузки начальной index.html-странички по HTTP2 подтягивается начальный javascript + css + плюс это колесико :)

Ну да. И пока бандл грузится, мы видим белую страницу. На хреновом мобильном соединении мы успеваем рассмотреть все оттенки белого. С SSR мы сразу видим отрисованное на сервере колёсико.

Если, конечно, у нас прямо в index.html не запилено одно большое колёсико на весь экран, на все случаи жизни %)

При использовании SSR на стороне сервера придется выполнить дополнительные API-запросы.

Если у вас внутри кластера сеть медленнее, чем пользовательский 3G — SSR вам не поможет, конечно. Впрочем, его отсутствие не поможет тоже %)

PWS

Этот? https://en.wikipedia.org/wiki/Prader%E2%80%93Willi_syndrome

Vue-движок вам придется грузить на клиент в любом случае. И отрисовывать начальную страницу повторно придется и на клиенте.

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

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

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

Возьмём тот же условный сервис рекомендаций. Он требует токен, и если мы хотим ходить за данными с клиента, мы должны хранить его на клиенте. Если ходить за данными с сервера и отдавать клиенту только готовый HTML, токен нужен будет только на сервере.

И, в общем-то, нет принципиальной разницы, делаем мы SSR нодой или безголовым браузером. И так, и так имеем вместо одного — два окружения, которые могут исполнять код — доверенное (серверное) и публичное (клиентское) вместо только клиентского.

Это добавляет сложности, но позволяет иметь некоторые преимущества (например, один язык и одна кодовая база для фронта и бэка). С другой стороны, серверное окружение у нас обычно всё равно есть (I’m PHP! I’m dynamite!), так что сложность не добавляется, просто перераспределяется.

обычно у веб приложений просто делают лендинг со ссылкой на приложение

нет, это работает не так, у ноды есть библиотека которая реализует DOM API. Фреймворку достаточно скормить бекенду часть своего кода, выполнится в ноде, и плюнуть поисковику html. Но это все бессмысленно т.к можно просто сделать лендинг для SEO, привлечения клиентов, etc. А приложение пусть висит на субдомене.

Ну типа:

hovesandhorns.com - лендос

app.hovesandhorns.com - приложение

Чем дрочить на SSR проще сделать так

PWS

Этот?

Опечатка - конечно PWA))

И пока бандл грузится, мы видим белую страницу. На хреновом мобильном соединении мы успеваем рассмотреть все оттенки белого.

Ну, если достаточно быстро загрузить ~200к - это суровая проблема для соединения, то конечно) Но сейчас ведь везде WiFi.

Но код для условной ленты рекомендаций, которая описана с помощью Vue, сформирована полностью на сервере и не имеет никакой интерактивности, кроме обычных ссылок, в бандл класть уже не нужно будет.

А как же скролирование ленты? Да и код для формирования такого фиксированного фрагмента - это мизер. Если у вас вообще не предполагается использование api-запросов, то зачем тогда frontend? Ну загрузили вы посредством SSR одну URL-ку - а все остальные-то будут формироваться уже на клиенте!

Возьмём тот же условный сервис рекомендаций. Он требует токен, и если мы хотим ходить за данными с клиента, мы должны хранить его на клиенте. Если ходить за данными с сервера и отдавать клиенту только готовый HTML, токен нужен будет только на сервере.

Не понял, что вы имеете в виду под термином «токен»? В моем понимании, это некая строка, которая передается в начальном HTTP-запросе и в последующих API-запросах в виде HTTP-хедера и без которой затребованные данные просто не будут возвращены клиенту. Если вы хотите высветить или обновить какие-то свои приватные данные, то вы должны в любом случае предоставить серверу этот самый токен.

код для формирования такого фиксированного фрагмента - это мизер

Пять старушек — рубль.

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

Ну да. Просто в случае с SSR это может сделать за вас ваш бэкенд, и лично вам (вашему клиентскому коду) этот токен иметь будет не обязательно. Достаточно будет аутентифицироваться на бэкенде, любым доступным способом.

обычно у веб приложений просто делают лендинг со ссылкой на приложение

о чём я и написал

нет, это работает не так

у автора родительского комментария это именно так и работает