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

Ну это не то, чтобы невозможно, но трудоёмко. Слишком значительны различия между фреймворками.

об участии фреймворка в потреблении серверных ресурсов

Так если стоит задача обеспечить отдачу сервером динамического HTML-контента, то так или иначе придётся какое-то серверное решение использовать. В случае SSR это будет изоморфный фреймворк, в случае классического рендеринга на бекенде — бекендный фреймворк или CMS. То есть серверные ресурсы всё равно кто-то потреблять будет.

Как такое возможно?

Лехко :) потому что UML диаграммы не глючат, а держать на проекте архитектора дораха, он может быть по выражению Кармака типичным «архитектурным астронавтом» из анекдота про мышей-ежиков «я стратегией занимаюсь, чо вы с фигней лезете». В «больших международных компаниях» (тм) случается, архитекторы привлекаются на этапе первоначальной декомпозиции, накидывают каку...ю-то спеку и улетает дальше по орбите, опылять более другие проекты. А когда через пару лет проект встречает «некоторые трудности развития», т.к. архитектор с бэком в энтерпрайзной жабе не учел особенности конкретной облачной платформы (ненужность слоя к базе, т.к. она встроенная и не может измениться примерно никогда), его опять дергают «чувак, посмотри чо там у посонов с твоей архитектурой», он приходит «покажите на этой диаграмме где сломалось», а его посылают «чумба, мы этот бред хлебушка выкосили к добру, а ты разобрался как платформа работает?» Архитектург обижается и больше не приходит. Да ему и некогда: он организовывает «школу архитектургов» имени себя где чешет по устаревшим книжкам про придуманное для жабы и гнет пальцы в интервью что... «ушел с производства когда пул его подшефных достиг 50 человек», а щас он на 20% ведет школу имени себя, а на остальные — курирует подшефные кадры... т.е. он больше кадровик, но с понтом архитектурга :) не умеешь сам — учи других (тм) Такой архитектор хорошо если не мешает со своими иницитивами. Так он плодит таких же :)

… так или иначе придётся какое-то серверное решение использовать

Просто я сторонник решения, которое тратит дополнительные серверные ресурсы исключительно на SEO в ответ на запросы, поступающие только от поисковых роботов (фильтруемые по UserAgent). Такое решение пашет как бы с боку и не усложняет обслуживание запросов обычных пользователей. Собственно, это единственная реальная альтернатива для SSR, появившаяся чуть раньше.

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

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

Так ничто не мешает и SSR так задействовать.

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

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

Можно поподробнее? На чём написан, что значит «пререндеринг»?

И как работает этот сервис пререндеринга? Запускает внутри себя браузерный движок, чтобы отрендерить очередной фронт?

Получает от бекэнда базовый код и данные. На основе этих данных генерирует html код. Там на js код.

Можно поподробнее?

https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering

Конкретный пример такого внешнего сервиса: https://prerender.io/

В качестве инструментария для написания можно использовать NodeJS + Puppeteer.

Я для своих целей просто свой сервис закодил частично позаимствовав логику Rendertron.

И как работает этот сервис …

см. выше

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

Кроме того, мы возвращаемся к теме снапшотов: «корректно выбрать момент снятия HTML-снапшота в принципе невозможно без какой-то договоренности с двух сторон»

Получает от бекэнда базовый код и данные. На основе этих данных генерирует html код.

Бакенд и пререндер на разных машинах?

В качестве инструментария для написания можно использовать NodeJS + Puppeteer.

Puppeteer is a Node.js library which provides a high-level API to control Chrome/Chromium over the DevTools Protocol.

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

на сервере гоняем Хром, чтобы он нам отрендерил наши странички

Да

на сервере гоняем Хром, чтобы он нам отрендерил наши странички

Да

«Есть в этом какое-то неестественное усложнение»

И как вы определяете момент снятия снапшота? То есть когда страница реально выполнила все необходимые запросы и отобразила пригодный для поисковика контент?

И как вы определяете момент снятия снапшота?

фронтовое приложение выставляет в DOM флажок - переменную с конкретным именем - когда можно снимать снапшот.

выставляет в DOM флажок

абсолютно не зависит от кодовой базы конкретных фронтовых проектов

сами себе противоречите

ну при желании можно и по таймауту))

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

Нравится вам SSR - пользуйте этот подход. Тут все еще зависит от доступности программистов соответствующей квалификации.

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

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

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

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

… сильно экономит ресурсы по сравнению с пререндерингом на браузерном движке?

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

У меня, например, в трехузловом K8S-кластере просто крутятся три реплики Nginx, раздающие фронтовый код для нескольких доменов, и три реплики prerender-сервиса, которые формируют снапшоты для этих доменов.

Зато эти сервисы будут значительно легче, чем жирные пререндеры.

Да, кстати, а как инвалидируете кеш страниц?

Зато эти сервисы будут значительно легче, чем жирные пререндеры.

Реальное время формирования снапшота конечно зависит от конкретного фронтового приложения. Движки Googlе Chrome постоянно висят в запущенном «разогретом» состоянии, так что затраты идут только на открытие страниц и выполнение внутренних запросов к backend-части - ну т.е. на работу Javascript-кода.

Да, кстати, а как инвалидируете кеш страниц?

Раз в сутки выполняется перезапуск пререндеров, чтобы устаревший код не болтался в их кеше. Javascript, CSS и пр. изменяемые файлы, естественно, меняют свои имена при обновлении версий.

Бакенд и пререндер на разных машинах?

Иногда да, это просто разные процессы.

на сервере гоняем Хром, чтобы он нам отрендерил наши странички

Да

ergo, зацени. :) Какая тебе трансформация за 10 лет? Тут поможет только ядерный апокалипсис. «Господь, жги.» А по завершению оного – деревянные счёты (или скорее костяные, деревья сгорят), на них хром не запустится.

UPD. Т.е. человек сначала демонстративно выпячивает своё старпёрство, но потом демонстрирует, что не закостенел на старости лет, продолжает развиваться, идёт в ногу со временем и с современными технологиями. :) Блин, я уже два часа сижу хихикаю. У психиатров это называется «шок»? :)

Невероятно ужасный ужас :(

Невероятно ужасный ужас :(

Ну что вам сказать… Зайдите на https://prerender.io - может всё покажется не таким уж и ужасным :)

Prerender currently serves 2.7 billion web pages to crawlers. Trusted by 65K developers and marketers across the globe.

Prerender currently serves 2.7 billion web pages to crawlers.

Я знаю, что такое Prerender/Puppeteer, мы его используем. Но для сугубо прикладных целей, узкоспециализированного краулера, да :)

Prerender и Puppeteer - это, в общем-то совершенно разные вещи. И 2.7 billion web pages - это не то, что посмотрели у других, а то что отдали поисковым роботам со своих сайтов :)

Я правильно понял, что человек использует это сугубо для поисковиков, как наименее затратный способ скармливать им «ХТМЛ» ?

А что в этом ужасного?

Честно говоря если бы у нас на фронтенде ходили в БД только когда клиенту на самом деле надо, а не флудили бы по 100 бессмысленных запросов на страницу - я был бы просто счастлив. Как уж там они ботов будут обманывать - глубоко пофиг. Хоть вручную. Ни живые люди, ни основные аппаратные мощности никак не страдают же.

Или я вообще не в теме?

Ностальжи.

В 1988 появились первые XT (Амстрады).
Все гоняли в Диггер и кошка какая-там по забору скакала.
А прикладного программного обеспечения не было.
Конкуренции НИКАКОЙ!.
Позаключал договора на разработку: «Учёт труда и заработной платы», «Основные фонды», «Учёт финансовых операций», «Учёт материалов», ...
Приехал в Центрпрограмм Систем.
Так у них было исходников более 2500 разных разработок «Учёт труда и заработной платы».
Исходники не брал, а мануалы по подсистемам были ВЕЛИКОЛЕПНЫ.
Если программист был не баобаб, то мог, используя их разработать любой АРМ.

Что и сделал (да ёщё с весьма удобным интерфейсом - иерархическое плиточное меню).

Шас спою.

«Дуракам везде у нас дорога, „учёным“ везде у нас почёт».

Prerender и Puppeteer - это, в общем-то совершенно разные вещи.

Посмотрю попозже в прод, вдруг ошибся :) Puppeteer точно есть до сих пор, prerender тоже вроде был.

а то что отдали поисковым роботам со своих сайтов

Я умею в английский, я пишу, как оно у нас используется.

как наименее затратный способ скармливать им «ХТМЛ» ?

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

ИМХО, опять же. После использования Puppeteer в проде.

Today, unless you are a tiny team building small apps, you probably invest in picking an ecosystem like React, Angular, or Vue or combining smaller frameworks with other tools to roll your own environment.

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

На современных мобилках нет многозадачности, и вот почему (комментарий)

Я сейчас придумал такую стратегию. Все, что можно написать вне фреймворка, на нормальных JS классах и функциях, писать вне фреймворка. Чтобы когда фреймворк выбросят, нормальный код можно было оставить. Ну и это просто экономит время.

Немного о разработке.

В 2024-2025 годах разработать API для использование баз знаний.
Далее ЯП «ТЗ» - техническое задание.

Шутка

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

Мы все дураки, так как у каждого из нас разработано несколько своих фреймворков.

prerender тоже вроде был.

Перепутал, был некоторое время в деве, кончился.

Да, кстати, а как инвалидируете кеш страниц?

Кеша страниц, если вы имели в виду кешировние готовых HTML-к, как такового нет. Поисковым ботам всегда выдаются текущие актуальные снапшоты страниц. Expires-хедеры можно конечно задавать разные на уровне Nginx - чтобы боты не слишком часто тыкались. Ну а обычным пользователям на все URL-ки выдается текущая версия index.html, которая разворачивается в конкретное содержимое страницы фронтовым приложением.

Что касается ассетов (js, css и пр), то при очередном деплое фронтовой части сохраняются ассеты нескольких предыдущих версий. Таким образом, работа пользователей, зашедших на сайт раньше текущего деплоя, не нарушается.

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

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

Это вроде бы не оскорбление

Наверное, у ойтишнеков обращение «молодой» (junior) считается уничижительным. Вроде как усомнился в опыте, профессионализме, длине бороды и ворсистости свитера. Забавная профдеформация.

Наверное, у ойтишнеков обращение «молодой» (junior) считается уничижительным

Ну вы же не это смысловое значение имели в виду, когда использовали речевой оборот «молодой человек») Вы явно пытались вещать с позиции этакого старого аксакала))

задолбали эти говнореакты

А какая альтернатива? Императивно жикверить DOM? Надоедает очень быстро, особенно если это не блог, где вся интерактивность — это форма отправки комментария, а нормальное приложение с множеством видов интерактивных элементов и сложным состоянием.

Реакты позволяют вместо лепки скульптур из навоза (ручная работа!) декларативно описывать сборку надёжных, предсказуемых и поддающихся пониманию интерфейсов из стандартных компонентов. Просто нарисовал дерево компонентов, и реактофиксики его собрали в готовый DOM (и следят, чтобы он оставался в соответствии с состоянием). Никакой ручной возни, никакого запаха, разве не прелесть? %)

Все, что можно написать вне фреймворка, на нормальных JS классах и функциях, писать вне фреймворка. Чтобы когда фреймворк выбросят, нормальный код можно было оставить

Поздравляю, вы только что изобрели Domain-Driven Design и Clean Architecture. Дядя Боб и Эрик Эванс гордятся вами %)

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

Обезглавленый хром имеет смысл использовать не дальше дев сервера где unit тесты гоняются. Что им там мешает генерировать шаблонами twig нужные страницы по запросу в апи, кешировать и потом отдавать через тот же nginx как статику мне решительно непонятно. Заодно настроить rate limiter для ботов чтобы не борзели, китайские оч борзые в этом плане.

Это все какое-то «архитекта не было, а до бекендщика мы не дозвонились».

явно пытались вещать с позиции этакого старого аксакала

Что поделаешь, мы увязли в нашей культуре, как мухи в янтаре. Мне больше нравится обращение «милостивый государь», но это уж точно будет воспринято как насмешка. Против культуры не попрёшь.

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