Содержание
Коротко
Большинство курсов учат собрать кнопку на React, но не объясняют, почему браузер её рисует, что происходит по 3G на бюджетном телефоне и как выбор стратегии рендеринга бьёт по бизнес-метрикам. На Dev.to — обзор «невидимой» части фронтенда, которую генераторы кода не заменят.
Что произошло
Автор противопоставляет «лёгкий фронтенд» инженерной дисциплине. Код уезжает на тысячи моделей устройств и версий браузеров; каждая миллисекунда задержки ощущается человеком, а не метрикой в Grafana.
В статье разложены блоки, которые редко проходят в начальных туториалах. Архитектура компонентов: композиция важнее наследования; у React, Vue и Angular разные модели мышления — не только синтаксис. Стратегии рендеринга: клиентский рендер (CSR), серверный (SSR), статическая генерация (SSG) и гибриды — выбор зависит от SEO, интерактивности и TTFB, а не от модного стека.
Состояние: локальное, поднятое вверх, контекст, серверное и внешнее хранилище — смешивать всё в одном Redux без нужды дорого. Производительность: размер бандла, блокировки главного потока, метрики Core Web Vitals (LCP, INP, CLS) влияют и на UX, и на поисковую выдачу. Отдельно — тестирование на реальных сетях и устройствах, а не только в DevTools на MacBook.
Почему это важно
ИИ-ассистенты ускоряют написание JSX и стилей, но не подменяют понимание конвейера браузера: парсинг HTML, построение дерева, раскладку, отрисовку, сеть, кэш, гидратацию. Ошибка в выборе CSR для контентного сайта или перегруз контекста ломает продукт так же надёжно, как баг в SQL — просто позже и на мобильном трафике.
Для карьеры это различие между «верстальщиком компонентов» и инженером, который может обосновать решение перед серверной частью и продуктом: почему здесь SSR, почему разбиение кода на части, где граница между UI-состоянием и данными с сервера.
На практике
- Для каждого экрана явно выберите модель рендеринга (CSR / SSR / SSG / islands) и зафиксируйте «почему» в ADR или README.
- Держите локальное состояние локально; поднимайте и выносите в контекст только при реальной необходимости.
- Замеряйте LCP, INP, CLS на сборке, близкой к продакшену, не только локально.
- Тестируйте с ограничением скорости сети (Slow 3G) и слабые устройства — эмулятор недостаточен.
- Следите за размером чанков и ленивой подгрузкой маршрутов; один тяжёлый импорт откатывает оптимизации.
- Читайте документацию платформы (MDN, web.dev), а не только API фреймворка.
Итог
Материал на Dev.to — напоминание, что фронтенд — это не «простая сторона» полного стека, а зона, где сходятся UX, сеть, платформа и архитектура. ИИ помогает писать код быстрее, но пробел в базовых знаниях он не закроет. Полный разбор — в оригинале.