Вы очень точно подметили про "иллюзию простоты". Никто не призывает возвращаться к ручному управлению памятью везде и всюду, но вот эта потеря связи между "написал строчку" и "понял, что произошло под капотом" действительно пугает. Рад, что мы на одной волне!
Секрет в том, что бизнесу (или "кабанычу") не нужно продавать "красивую архитектуру". Ему нужно продавать метрики и деньги. Если фича, написанная за 1 день, заставляет приложение тормозить на бюджетных Android-смартфонах, конверсия падает, и бизнес теряет деньги. Плюс, не отдавать на фронт всю таблицу из БД вместе с техническими и неиспользуемыми на клиенте полями – это не N дней работы, это просто грамотно написанный DTO/сериализатор, который пишется за те же 15 минут, но экономит мегабайты.
Именно) JSON – прекрасный инструмент. Формат ни в чем не виноват. Виновато отношение, при котором "раз это текст и он гибкий, значит можно запихивать в него вообще всё подряд без разбора, фронтенд сам отфильтрует". Об этом и речь.
Микрооптимизации и переписывание на Rust ради 5мс без бизнес-цели – это зло. Но в статье речь не о преждевременной оптимизации, а о базовой инженерной гигиене. Спроектировать API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн. Чинить это потом, когда база ляжет от рекурсивных джойнов, а клиенты начнут жаловаться на лаги – обойдется бизнесу в десятки раз дороже.
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 и ко) просто для продажи своей инфраструктуры. Упрощать им невыгодно.
Вы очень точно подметили про "иллюзию простоты". Никто не призывает возвращаться к ручному управлению памятью везде и всюду, но вот эта потеря связи между "написал строчку" и "понял, что произошло под капотом" действительно пугает. Рад, что мы на одной волне!
Секрет в том, что бизнесу (или "кабанычу") не нужно продавать "красивую архитектуру". Ему нужно продавать метрики и деньги. Если фича, написанная за 1 день, заставляет приложение тормозить на бюджетных Android-смартфонах, конверсия падает, и бизнес теряет деньги. Плюс, не отдавать на фронт всю таблицу из БД вместе с техническими и неиспользуемыми на клиенте полями – это не N дней работы, это просто грамотно написанный DTO/сериализатор, который пишется за те же 15 минут, но экономит мегабайты.
Именно) JSON – прекрасный инструмент. Формат ни в чем не виноват. Виновато отношение, при котором "раз это текст и он гибкий, значит можно запихивать в него вообще всё подряд без разбора, фронтенд сам отфильтрует". Об этом и речь.
Микрооптимизации и переписывание на Rust ради 5мс без бизнес-цели – это зло. Но в статье речь не о преждевременной оптимизации, а о базовой инженерной гигиене. Спроектировать API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн. Чинить это потом, когда база ляжет от рекурсивных джойнов, а клиенты начнут жаловаться на лаги – обойдется бизнесу в десятки раз дороже.
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