Gzip действительно отлично жмет повторяющиеся ключи в JSON, и реальный egress-трафик будет меньше 'сырых' мегабайтов. Но проблема в том, что уникальные текстовые данные, вложенные структуры и избыточные метаданные (те же длинные токены, id и лишние base64) сжимаются хуже. К тому же, чем больше мы сэкономили на трафике за счет gzip, тем больше тактов CPU смартфона мы сожжем на декомпрессию этого "жира" перед тем, как отдать его парсеру. Так что за мусорные данные мы всё равно платим: либо рублями провайдеру, либо батареей пользователя.
Вы правы в деталях механики. Парсингом действительно занимается JS-движок (Hermes/V8). Но проблема возникает как раз на стыке: когда нам нужно прокинуть этот огромный массив данных для рендера списков на нативную сторону. В старой архитектуре это приводило к сериализации/десериализации при переходе через мост. В новой JSI (которую я упоминаю) это решается ссылками на C++ объекты, но аллокация огромного количества памяти под "мусорные" поля из ответа всё равно нагружает GC и съедает ресурсы процессора.
Спасибо за интерес! Да, конечно. Напишите мне в личку здесь или в Telegram (ссылка в профиле) — договоримся, как это лучше организовать, с радостью подпишу.
Сегодня сам получил печатный экземпляр, проверял как сервис печати по требованию работает. В целом неплохо.
Спасибо за комментарий! Вы правы: писать сложный интерактивный SPA в большой команде на ванильном JS или jQuery – это выстрел в ногу. Это будет стоить дорого и быстро превратится в легаси.
Пример с «Hello World» – это намеренная гипербола, чтобы подсветить базовый оверхед, который современный стек тянет за собой.
Как я и отмечаю в статье: фреймворки отлично дают архитектурный каркас для большой команды. Боль в другом – сейчас этот тяжелый стек начали тащить по дефолту вообще везде: в статичные лендинги, простые блоги и визитки. Фреймворк перестал быть осознанным решением под уровень задачи.
Интересно ваше мнение: где, по-вашему, сейчас проходит адекватная граница применимости того же Next.js? С какого масштаба проекта он начинает полностью окупать свой вес?
Абсолютно согласен. Экосистема React не позволяет написать код «один раз и навсегда». Я сам участвовал во вскрытии такого легаси: мобильное приложение известного ТЦ на юге РФ, написанное на React Native.
Приложение спокойно жило и работало годами, пока не вышел очередной апдейт iOS, сломавший всё. Чтобы просто заставить этот "современный" стек запуститься, нужно было мигрировать через 3 мажорные версии и разгрести ад зависимостей. Бизнес посмотрел на смету работ и просто похоронил приложение.
Вы правы: цена поддержки такого кода космическая, потому что ты платишь не за новые фичи, а за то, чтобы старый код просто компилировался.
А где я их жалею? При прочих равных, поисковик лучше индексирует сайт с SSR, а не SPA.
Ни Гугл, ни Яндекс не раскрывают своих алгоритмов поискового продвижения, все познается эмпирическим путем. И за эти знания спасибо моей команде прекрасных специалистов💪
Это не отменяет того, что парсеру нужен готовый HTML от сервера. Разница лишь в том, что теперь в поисковиках есть ИИ-сводка, которую ранее тупые боты уже спарсили и продолжают это делать. SEO не уходит, оно просто видоизменяется.
Гугл и яндекс умеют парсить SPA. Только спарсить готовый HTML гораздо легче, чем SPA. Запускать V8 в хедлесс хром для каждого маршрута SPA – дорого по серверному времени. Поэтому поисковики просто пессимизируют тяжелую статику, а бизнес ушел обратно в SSR.
Это отличный паттерн, если у вас четкое разделение: контентный сайт отдельно, а сложный ЛК – отдельно за авторизацией.
Но что делать, если это интернет-магазин, СМИ или портал, где контент перемешан с интерактивом (динамические цены, фильтры, корзина, сложный поиск)? Генерить статику для ботов и параллельно собирать SPA для живых людей – это буквально делать двойную работу и поддерживать две кодовые базы для одних и тех же страниц.
Именно из-за этой боли с пререндерами индустрия в свое время так радостно и бросилась в SSR (Next/Nuxt), чтобы писать код один раз. Но в итоге мы получили не "лучшее из двух миров", а сложность обоих подходов в квадрате.
Я сам на днях чуть не попался в эту ловушку. Решил сделать сайт для книги и уже начал перебирать шаблоны на Next/Vue. Вовремя опомнился, написал за пару вечеров чистый HTML с капелькой JS, положил на копеечный хостинг – работает идеально. Без сюрпризов, билдов и node_modules на 500 мегабайт)
Отличный поинт про DDoS, честно говоря, я этот аспект даже не рассматривал в статье) А ведь связка SPA + CDN – это самая дешевая и неубиваемая инфраструктура.
Вся шиза с возвратом рендеринга на сервер началась исключительно из-за SEO – и теперь SEO-адаптированные сайты просто стали модными и дорогими.
Золотые слова. «Создать себе проблемы, чтобы героически их решать» – это сегодня девиз индустрии.
Выстраивание 15 слоев абстракций вокруг вывода строки HTML стало нашей зоной комфорта. Бизнес за это платит временем и дорогими серверами, а мы – выгоранием, пытаясь собрать этот карточный домик из Webpack, гидратации и бандлов.
Точно подмечено. Разница лишь в том, что Go создавали инженеры для решения бизнес-проблем Google. А современные веб-абстракции часто создаются вендорами (Vercel и ко) просто для продажи своей инфраструктуры. Упрощать им невыгодно.
«Ну API же, что сложного» – это вообще девиз, который надо писать на надгробиях проектов. Батчи и спайки нагрузки – это как раз то, о чем фронтендер обычно не думает (у нас же Event Loop, оно само разрулится).
Про кэш:
Сначала хотел сделать «умную» инвалидацию через хуки Strapi (onUpdate -> clear cache). Но быстро понял, что задача усложняется связанными сущностями (обновил новость -> надо сбросить кэш списка новостей -> и кэш главной).
В итоге пришел к самому надежному (и стыдному) решению: кнопка «Сбросить» в админке. Маркетинг сам решал, когда им нужно обновить данные. И это сработало лучше любой автоматики)
Согласен про пересечение компетенций. Знать (а лучше уметь) всё – полезно.
Но давайте честно: сколько таких специалистов «выше среднего», о которых вы говорите? 5%? Моя статья про остальные 95%, которые приходят на бэкенд с ментальностью npm install и «оно само соберется».
Фронтендер привык думать категориями: «Как это выглядит? Быстро ли отрисовалось? Удобно ли пользователю?». Бэкендер должен думать: «Что будет при параллельных запросах? Как это мигрировать через год? Выдержит ли база?».
Когда ты приходишь на бэк со старой «фронтендерской прошивкой», ты инстинктивно оптимизируешь не то. Ты делаешь красивый API, но забываешь про транзакции. Ты кешируешь всё подряд ради скорости, но получаешь неконсистентность данных.
Фуллстек – это круто, когда ты переключаешь этот тумблер в голове. А я его переключать даже не умел, просто не было соответствующего опыта. Я попал в те 95%.
С высоты опыта всё кажется простым. Но суть статьи именно в трансформации мышления.
Когда ты всю жизнь мыслишь категориями npm install и import Component, необходимость конфигурировать базу данных вызывает ступор. Это сейчас я понимаю, что это базовые знания. А тогда это была магия.
И да, эникейщик бы справился быстрее. Но я не эникейщик, я инженер, который учился на своих ошибках. И эта ошибка стоила мне нервов и бессонных ночей, зато теперь я знаю цену своим решениям.
Gzip действительно отлично жмет повторяющиеся ключи в JSON, и реальный egress-трафик будет меньше 'сырых' мегабайтов. Но проблема в том, что уникальные текстовые данные, вложенные структуры и избыточные метаданные (те же длинные токены, id и лишние base64) сжимаются хуже. К тому же, чем больше мы сэкономили на трафике за счет gzip, тем больше тактов CPU смартфона мы сожжем на декомпрессию этого "жира" перед тем, как отдать его парсеру. Так что за мусорные данные мы всё равно платим: либо рублями провайдеру, либо батареей пользователя.
Вы правы в деталях механики. Парсингом действительно занимается JS-движок (Hermes/V8). Но проблема возникает как раз на стыке: когда нам нужно прокинуть этот огромный массив данных для рендера списков на нативную сторону. В старой архитектуре это приводило к сериализации/десериализации при переходе через мост. В новой JSI (которую я упоминаю) это решается ссылками на C++ объекты, но аллокация огромного количества памяти под "мусорные" поля из ответа всё равно нагружает GC и съедает ресурсы процессора.
Спасибо за интерес! Да, конечно. Напишите мне в личку здесь или в Telegram (ссылка в профиле) — договоримся, как это лучше организовать, с радостью подпишу.
Сегодня сам получил печатный экземпляр, проверял как сервис печати по требованию работает. В целом неплохо.
Не могу утверждать, но уверен, что сначала поисковые боты отрабатывают, а потом уже поверх собранных данных накручивается ИИ
Спасибо за комментарий! Вы правы: писать сложный интерактивный SPA в большой команде на ванильном JS или jQuery – это выстрел в ногу. Это будет стоить дорого и быстро превратится в легаси.
Пример с «Hello World» – это намеренная гипербола, чтобы подсветить базовый оверхед, который современный стек тянет за собой.
Как я и отмечаю в статье: фреймворки отлично дают архитектурный каркас для большой команды. Боль в другом – сейчас этот тяжелый стек начали тащить по дефолту вообще везде: в статичные лендинги, простые блоги и визитки. Фреймворк перестал быть осознанным решением под уровень задачи.
Интересно ваше мнение: где, по-вашему, сейчас проходит адекватная граница применимости того же Next.js? С какого масштаба проекта он начинает полностью окупать свой вес?
Абсолютно согласен. Экосистема React не позволяет написать код «один раз и навсегда». Я сам участвовал во вскрытии такого легаси: мобильное приложение известного ТЦ на юге РФ, написанное на React Native.
Приложение спокойно жило и работало годами, пока не вышел очередной апдейт iOS, сломавший всё. Чтобы просто заставить этот "современный" стек запуститься, нужно было мигрировать через 3 мажорные версии и разгрести ад зависимостей. Бизнес посмотрел на смету работ и просто похоронил приложение.
Вы правы: цена поддержки такого кода космическая, потому что ты платишь не за новые фичи, а за то, чтобы старый код просто компилировался.
А где я их жалею? При прочих равных, поисковик лучше индексирует сайт с SSR, а не SPA.
Ни Гугл, ни Яндекс не раскрывают своих алгоритмов поискового продвижения, все познается эмпирическим путем. И за эти знания спасибо моей команде прекрасных специалистов💪
Навеяло ностальгию)
Помню, как в 2015 с помощью gulp подкидывал общие сквозные элементы🥲
Это не отменяет того, что парсеру нужен готовый HTML от сервера. Разница лишь в том, что теперь в поисковиках есть ИИ-сводка, которую ранее тупые боты уже спарсили и продолжают это делать.
SEO не уходит, оно просто видоизменяется.
Гугл и яндекс умеют парсить SPA. Только спарсить готовый HTML гораздо легче, чем SPA. Запускать V8 в хедлесс хром для каждого маршрута SPA – дорого по серверному времени. Поэтому поисковики просто пессимизируют тяжелую статику, а бизнес ушел обратно в SSR.
Это отличный паттерн, если у вас четкое разделение: контентный сайт отдельно, а сложный ЛК – отдельно за авторизацией.
Но что делать, если это интернет-магазин, СМИ или портал, где контент перемешан с интерактивом (динамические цены, фильтры, корзина, сложный поиск)? Генерить статику для ботов и параллельно собирать SPA для живых людей – это буквально делать двойную работу и поддерживать две кодовые базы для одних и тех же страниц.
Именно из-за этой боли с пререндерами индустрия в свое время так радостно и бросилась в SSR (Next/Nuxt), чтобы писать код один раз. Но в итоге мы получили не "лучшее из двух миров", а сложность обоих подходов в квадрате.
Я сам на днях чуть не попался в эту ловушку. Решил сделать сайт для книги и уже начал перебирать шаблоны на Next/Vue. Вовремя опомнился, написал за пару вечеров чистый HTML с капелькой JS, положил на копеечный хостинг – работает идеально. Без сюрпризов, билдов и node_modules на 500 мегабайт)
Отличный поинт про DDoS, честно говоря, я этот аспект даже не рассматривал в статье)
А ведь связка SPA + CDN – это самая дешевая и неубиваемая инфраструктура.
Вся шиза с возвратом рендеринга на сервер началась исключительно из-за SEO – и теперь SEO-адаптированные сайты просто стали модными и дорогими.
Золотые слова. «Создать себе проблемы, чтобы героически их решать» – это сегодня девиз индустрии.
Выстраивание 15 слоев абстракций вокруг вывода строки HTML стало нашей зоной комфорта. Бизнес за это платит временем и дорогими серверами, а мы – выгоранием, пытаясь собрать этот карточный домик из Webpack, гидратации и бандлов.
Спасибо за крутой и очень жизненный комментарий)
Точно подмечено. Разница лишь в том, что Go создавали инженеры для решения бизнес-проблем Google. А современные веб-абстракции часто создаются вендорами (Vercel и ко) просто для продажи своей инфраструктуры. Упрощать им невыгодно.
Примерно 2019 год, strapi v3
Самое смешное, что мы сделали полный круг. Server Actions в Next.js – это буквально php, только с типизацией.
«Ну API же, что сложного» – это вообще девиз, который надо писать на надгробиях проектов. Батчи и спайки нагрузки – это как раз то, о чем фронтендер обычно не думает (у нас же Event Loop, оно само разрулится).
Про кэш:
Сначала хотел сделать «умную» инвалидацию через хуки Strapi (onUpdate -> clear cache). Но быстро понял, что задача усложняется связанными сущностями (обновил новость -> надо сбросить кэш списка новостей -> и кэш главной).
В итоге пришел к самому надежному (и стыдному) решению: кнопка «Сбросить» в админке. Маркетинг сам решал, когда им нужно обновить данные. И это сработало лучше любой автоматики)
Согласен про пересечение компетенций. Знать (а лучше уметь) всё – полезно.
Но давайте честно: сколько таких специалистов «выше среднего», о которых вы говорите? 5%? Моя статья про остальные 95%, которые приходят на бэкенд с ментальностью
npm installи «оно само соберется».Фронтендер привык думать категориями: «Как это выглядит? Быстро ли отрисовалось? Удобно ли пользователю?».
Бэкендер должен думать: «Что будет при параллельных запросах? Как это мигрировать через год? Выдержит ли база?».
Когда ты приходишь на бэк со старой «фронтендерской прошивкой», ты инстинктивно оптимизируешь не то. Ты делаешь красивый API, но забываешь про транзакции. Ты кешируешь всё подряд ради скорости, но получаешь неконсистентность данных.
Фуллстек – это круто, когда ты переключаешь этот тумблер в голове. А я его переключать даже не умел, просто не было соответствующего опыта. Я попал в те 95%.
С высоты опыта всё кажется простым. Но суть статьи именно в трансформации мышления.
Когда ты всю жизнь мыслишь категориями
npm installиimport Component, необходимость конфигурировать базу данных вызывает ступор. Это сейчас я понимаю, что это базовые знания. А тогда это была магия.И да, эникейщик бы справился быстрее. Но я не эникейщик, я инженер, который учился на своих ошибках. И эта ошибка стоила мне нервов и бессонных ночей, зато теперь я знаю цену своим решениям.