Спасибо за комментарий! Вы правы: писать сложный интерактивный 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, необходимость конфигурировать базу данных вызывает ступор. Это сейчас я понимаю, что это базовые знания. А тогда это была магия.
И да, эникейщик бы справился быстрее. Но я не эникейщик, я инженер, который учился на своих ошибках. И эта ошибка стоила мне нервов и бессонных ночей, зато теперь я знаю цену своим решениям.
Теория одна – согласен, но «бытовое» применение отличается. Фронтенд чаще бьется за FPS и перерисовки, а бэкенд – за IO и память.
По моим наблюдениям, переключиться именно с фронта на бэк особенно сложно. Теряется привычная визуальная опора, меняется сама парадигма: от событийной модели UI к транзакциям и работе с данными.
Инерция мышления тут часто играет злую шутку: разработчики по привычке пытаются перенести UI-паттерны в бэкенд-архитектуру «один в один».
Подробностей уже не вспомню, но была ошибка, которою сходу устранить не смог. Поэтому просто с 0 развернул strapi, поставив галочку напротив mongodb. Тогда для меня большой разницы между этими БД не было, главное чтобы работало.
Спасибо за комментарий! Вы правы: писать сложный интерактивный 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, необходимость конфигурировать базу данных вызывает ступор. Это сейчас я понимаю, что это базовые знания. А тогда это была магия.И да, эникейщик бы справился быстрее. Но я не эникейщик, я инженер, который учился на своих ошибках. И эта ошибка стоила мне нервов и бессонных ночей, зато теперь я знаю цену своим решениям.
Теория одна – согласен, но «бытовое» применение отличается. Фронтенд чаще бьется за FPS и перерисовки, а бэкенд – за IO и память.
По моим наблюдениям, переключиться именно с фронта на бэк особенно сложно. Теряется привычная визуальная опора, меняется сама парадигма: от событийной модели UI к транзакциям и работе с данными.
Инерция мышления тут часто играет злую шутку: разработчики по привычке пытаются перенести UI-паттерны в бэкенд-архитектуру «один в один».
Подробностей уже не вспомню, но была ошибка, которою сходу устранить не смог. Поэтому просто с 0 развернул strapi, поставив галочку напротив mongodb. Тогда для меня большой разницы между этими БД не было, главное чтобы работало.
101 или 1001?)
Спасибо за статью. Решаю подобную задачу сейчас, но без использования сторонних сервисов. Нужно развернуть локальную модель на железе 4cpu 4-8gb