9. Был свет истинный, который регает здоровье каждого игрока, входящего в мир.

10. В мире он был, и мир через него был заспавнен, но мир не узнал его в логах.

11. Пришёл к своим, и свои его не приняли.

12. А тем, которые запустили его через java -jar, верящим в его алгоритм, дал право быть чадами креатива.

13. Которые не от плоти и крови, но от семени возродились в новом чанке.

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

15. Херобрин багует о нём и крашит: «Сей был Тот, о ком я сказал: Идущий за мной в очереди тик-цикла стал впереди меня, потому что был объявлен ранее (public static void main)».

16. И от перегрузки процессора его мы приняли и TPS на TPS,

17. ибо закон крафта дан через Печь; благодать же и редстоун произошли через Поршень.

18. Сущность не видел никто никогда; Единственный Загрузчик, сущий в недрах Main.class, Он явил патч-ноут.

Минусы:

• Долгая первая загрузка (Time to Interactive)Долгая первая загрузка (Time to Interactive)

• Плохо для SEO — боты видят пустой HTML

• Требует хорошего интернета у пользователя

Главная проблема CSR — поисковые боты. Googlebot умеет выполнять JavaScript, но делает это с задержкой и не всегда корректно. Яндекс справляется хуже. В итоге страницы индексируются медленнее и хуже.

Когда CSR — правильный выбор:

•  Дашборды и админки за авторизацией — SEO не нужен

•  SPA с богатой интерактивностью: редакторы, конструкторы, таблицы

•  Внутренние инструменты компании

•  Приложения, где пользователь авторизован и контент персональный

SSR — Server-Side Rendering

При каждом запросе сервер генерирует готовый HTML с данными и отдаёт его браузеру. Пользователь сразу видит контент — не надо ждать, пока выполнится JavaScript.

Плюсы:

• Отличный SEO — боты видят готовый HTML

• Актуальные данные на каждый запрос

Минусы:

• Нагрузка на сервер при каждом запросе

• Медленнее навигация, чем CSR

• Нужен сервер — хостинг дороже

SSR — лучший выбор для SEO-важных страниц. Поисковик получает готовый HTML с контентом, мета-тегами и структурированными данными. Индексация быстрее и надёжнее, чем при CSR.

Когда SSR — правильный выбор:

•  Интернет-магазины — карточки товаров должны индексироваться

•  Новостные сайты и блоги с часто меняющимся контентом

•  Страницы с персонализированным контентом (лента, рекомендации)

•  Любые публичные страницы, где важен SEO и актуальность данных

SSG — Static Site Generation

HTML генерируется один раз — во время сборки проекта. Готовые файлы раздаются с CDN без участия сервера. Это самый быстрый способ доставить контент пользователю.

Плюсы:

• Максимальная скорость

• Отличный SEO

• Дешёвый хостинг — просто файлы

• Высокая надёжность — нет сервера

Минусы:

• Данные могут быть устаревшими

• Долгая сборка при большом числе страниц

• Не подходит для часто меняющихся данных

Когда SSG — правильный выбор:

•  Лендинги и маркетинговые сайты

•  Документация и справочники

•  Блоги и портфолио

•  Сайты, где контент меняется редко или по расписанию

Главное про SEO

SEO — это часто решающий фактор при выборе рендеринга. Вот простое правило:

•  Страница публичная и должна находиться в поиске → SSR или SSG

•  Страница за авторизацией или контент персональный → CSR

•  Контент меняется часто → SSR

•  Контент меняется редко → SSG

Отдельно про Core Web Vitals — Google учитывает LCP, FID и CLS в ранжировании. SSG и SSR дают лучшие показатели, чем CSR по умолчанию, но и CSR можно оптимизировать через lazy loading, code splitting и prefetching.

Хорошая новость: Next.js позволяет миксовать все подходы в одном проекте. Лендинг — SSG, карточка товара — SSR, личный кабинет — CSR. Именно поэтому он стал стандартом индустрии.

Больше материалов про разработку и запуск своих продуктов — в Telegram-канале @deep_in_prod

Часть живёт на сервере: рендеринг, подготовка данных, проверка прав. Часть - в браузере: интерактивность, ввод, мгновенная обратная связь. Часть - в кэше: CDN, query cache, prefetch, service worker. А часть вообще не выглядит как Frontend: она в контракте API, в схеме данных, в дизайн-системе, в правилах релиза.

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

Кнопка не просто вызывает onClick. Она может запускать optimistic update, инвалидировать кэш, отправлять событие аналитики, менять URL, зависеть от прав пользователя, показывать pending-состояние, откатывать UI после ошибки или повторять запрос.

Это уже не «покрасить кнопку». Это проектирование поведения системы в условиях неопределённости.

Компоненты не спасают архитектуру

Когда Frontend стал сложнее, мы нашли удобный ответ - компонентную модель. Разбей интерфейс на части, переиспользуй их, собери экран из маленьких элементов. Сильная идея, но без неё современные интерфейсы было бы трудно поддерживать.

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

Самая частая ошибка - смешать UI-состояние, серверные данные, процесс сохранения, ошибки и производные значения в одном месте. Тогда форма знает про API, кнопка - про бизнес-правила, таблица - про инвалидирование кэша, а страница хранит копию данных из query cache «на всякий случай». Дальше начинаются исключения, быстрые фиксы, дублирование, страх менять экран и фраза «проще переписать».

Redux, Zustand, React Query, SWR, Signals, Context - ни один инструмент не решит за команду главный вопрос: где источник правды.

Если правда на сервере, Frontend должен уважать сервер и не показывать пользователю фантомное состояние. Если правда в пользовательском вводе, нельзя терять его после refetch. Если правда в URL, состояние должно переживать перезагрузку и передаваться ссылкой. Плохая архитектура начинается там, где источник не выбран: сервер говорит одно, кэш помнит другое, форма хранит третье, URL показывает четвёртое, а компонент делает пятое, потому что «так быстрее».

Где должна жить логика

Главный вопрос: кто за что отвечает, и что произойдёт, когда что-то пойдёт не так.

Возьмём простой сценарий - пользователь переименовывает проект.

Слабая версия: Пользователь жмёт «Сохранить». Форма отправляет PATCH, показывает спиннер. Через 800 мс ответ приходит, спиннер исчезает, имя в форме обновляется. Хорошо. Но в сайдбаре имя меняется ещё через секунду, потому что список проектов перезапрашивается отдельно. А в соседней вкладке, открытой час назад, имя вообще старое. Пользователь видит три разных состояния одной сущности и не понимает, какому верить.

Сильная версия: То же действие. Имя в инпуте меняется мгновенно - здесь источник правды сам пользователь. После сабмита UI сразу показывает новое имя во всех местах: в сайдбаре, в заголовке, в хлебных крошках, но визуально помечает его как ещё не сохранённое (например, приглушённым цветом). Если сервер подтвердил, тогда пометка исчезает. Если вернул ошибку - UI откатывается к старому имени и показывает причину человеческим языком: «нет прав» или «имя уже занято». Список проектов в кэше обновляется по одному правилу, а не по совпадению.

Из этого вытекает несколько практических правил.

Источник правды - один на каждое значение. Если правда на сервере, Frontend читает её оттуда и не хранит копий «на всякий случай». Если правда в URL - фильтры, поиск, выбранная вкладка, она переживает перезагрузку и передаётся ссылкой. Если правда во вводе пользователя, её нельзя потерять при refetch. Дублирование источников - это не ускорение, это будущий баг.

Frontend не решает то, за что не отвечает. Он может скрыть кнопку под роль пользователя, но не должен сам определять, разрешено ли действие. Это решает сервер. Frontend может показать бизнес-правило и объяснить его, но само правило живёт в домене, а не в компоненте. Если правило про деньги, права или статусы случайно осело в JSX, его рано или поздно нарушат.

Кэш это договор, а не оптимизация. Когда мы держим данные в query cache, мы говорим пользователю: «верь этому, пока я не скажу обратное». У договора должны быть условия: сколько данным можно верить, кто их обновляет, когда инвалидировать, что показывать, если они устарели. Быстрый интерфейс не должен быстро врать.

Производительность и ошибки

Производительность часто сводят к Lighthouse, Core Web Vitals и размеру бандла. Метрики полезны, но не объясняют главного.

Пользователь не обязан ждать. Медленный Frontend почти всегда - сумма решений: слишком много клиентского кода, тяжёлая дизайн-система, водопад запросов, дорогой рендер, небрежная гидратация. Это нельзя починить в конце. Это проектируется в начале: что отдать с сервера, что загрузить заранее, что отложить, какой экран остаётся полезным при частичном отказе.

С ошибками то же самое. В продакшене сеть медленная, API отвечает не сразу, сессия истекает, пользователь кликает быстро, данные меняются в другой вкладке. Ошибка валидации должна жить рядом с формой. Ошибка прав - приходить от сервера. Ошибка сети - объяснять, можно ли повторить действие. Ошибка бизнес-правила должно быть написана по-человечески: не «400 Bad Request», а «Нельзя удалить проект, пока в нём есть активные задачи».

Надёжность Frontend - это не отсутствие ошибок в консоли. Это способность интерфейса вести себя предсказуемо, когда мир вокруг неидеален.

Что отличает сильного Frontend-инженера

Не количество выученных хуков и не скорость написания компонентов. Он понимает границы: где заканчивается серверное состояние и начинается клиентское, где данные можно кэшировать, где нужна мгновенная реакция, а где честный loading, где типы помогают, а где нужна runtime-проверка, где абстракция снижает стоимость изменений, а где делает код мутным.

Он проектирует не только компоненты, но и договоры: между клиентом и сервером, между страницей и компонентом, между системой и пользователем.

Плохая архитектура почти всегда выглядит нормально в первый месяц. Потом она начинает требовать всё больше энергии за всё меньший результат. Переписывать приходится не потому, что React плохой или Vue плохой. Чаще всего в начале никто не ответил на скучные вопросы: что является источником правды, какие данные могут устареть, что пользователь увидит при медленной сети, что произойдёт, если запрос выполнится дважды, какая логика принадлежит домену, а какая - интерфейсу.

Заключение

Frontend больше не тонкая оболочка вокруг API. Он стал местом, где техническая архитектура встречается с человеческим ожиданием. Пользователь не видит server components, query cache, hydration и source of truth. Он видит другое: страница открылась или нет, действие сохранилось или потерялось, ошибка объяснена или спрятана, интерфейс помогает или заставляет сомневаться.

Frontend - это слой доверия. Он отвечает за договор между человеком и системой: нажал - увидел реакцию, сохранил - понял результат, ошибся - понял, как исправить, вернулся - попал туда, где ожидал быть. Хорошая архитектура не убирает сложность. Она кладёт её туда, где её можно понять.

Этой вводной статьёй я хотел поделиться мыслями и начать этот блог. Всем спокойных релизов и поменьше багов в продакшене ❤

ТРЕНИРОВКА ПАМЯТИ

Программа для развития навыков запоминания.

Уважаемые читатели!

Предлагаю вашему вниманию программу «ТРЕНИРОВКА ПАМЯТИ»

Простой и эффективный инструмент для развития способности запоминать важную информацию.Простота и надёжность.Программа выполнена в лучших традициях DOS-эпохи: ничего лишнего, только функциональность. Минималистичный интерфейс, мгновенный запуск, отсутствие сложных настроек — всё работает быстро и понятно.

Это именно тот случай, когда простота означает качество.Что тренирует программа? Программа фокусируется на запоминании трёх типов информации, которые наиболее востребованы в повседневной жизни:

1 - Телефонные номера — для быстрого набора без подглядывания в контакты
2 - Адреса (улица, дом, корпус, квартира) — чтобы не теряться в незнакомых местах
3 - ФИО, организации и должности — для уверенного общения в деловой среде

Именно эти данные мы чаще всего забываем в самый неподходящий момент. Регулярные тренировки помогут довести запоминание до автоматизма.Принцип работы:Программа показывает информацию на ограниченное время (от 20 до 40 секунд в зависимости от сложности), после чего предлагает воспроизвести её по памяти.

За каждый правильный ответ начисляется балл, за ошибку — снимается. Цель — набрать 20 баллов.

Почему это работает?

Все временные интервалы рассчитаны таким образом, чтобы создать оптимальную нагрузку на кратковременную память. Это заставляет мозг концентрироваться и эффективно кодировать информацию. Регулярные занятия по 10-15 минут в день дадут заметный результат уже через 2-3 недели.

Технические требования:

Программа работает в любом современном браузере, не требует установки и интернета.
Достаточно просто открыть HTML-файл.

Хочу добавить, что я, не имея навыков программирования на Java script написал ее при помощи нейросети. Я сформулировал архитектуру и логику этой программы и достаточно быстро получил работающий код.

СКАЧАТЬ ПРОГРАММУ ПО ССЫЛКЕ: disk.yandex.ru/d/dS7WVkbS...