Зміст
Коротко
Більшість курсів учать зібрати кнопку на React, але не пояснюють, чому браузер її малює, що відбувається по 3G на бюджетному телефоні й як вибір стратегії рендерингу б'є по бізнес-метриках. На Dev.to — огляд «невидимої» частини фронтенду, яку генератори коду не замінять.
Що сталося
Автор протиставляє «легкий фронтенд» інженерній дисципліні. Код їде на тисячі моделей пристроїв і версій браузерів; кожна мілісекунда затримки відчувається людиною, а не метрикою в Grafana.
У статті розкладені блоки, які рідко проходять у intro-туторіалах. Архітектура компонентів: композиція важливіша за успадкування; у React, Vue і Angular різні моделі мислення — не лише синтаксис. Стратегії рендерингу: клієнтський рендер (CSR), серверний (SSR), статична генерація (SSG) і гібриди — вибір залежить від SEO, інтерактивності й TTFB, а не від модного стеку.
Стан: локальний, піднятий вгору, контекст, серверний і зовнішнє сховище — змішувати все в одному Redux без потреби дорого. Продуктивність: розмір бандла, блокування головного потоку, метрики Core Web Vitals (LCP, INP, CLS) впливають і на UX, і на пошукову видачу. Окремо — тестування на реальних мережах і пристроях, а не лише в DevTools на MacBook.
Чому це важливо
ШІ-асистенти прискорюють написання JSX і стилів, але не підміняють розуміння конвеєра браузера: парсинг HTML, побудова дерева, layout, paint, мережа, кеш, гідратація. Помилка у виборі CSR для контентного сайту або перевантаження контексту ламає продукт так само надійно, як баг у SQL — просто пізніше й на мобільному трафіку.
Для кар'єри це відмінність між «верстальником компонентів» і інженером, який може обґрунтувати рішення перед backend і продуктом: чому тут SSR, чому розбиття коду на частини, де межа між UI-станом і даними з сервера.
На практиці
- Для кожного екрана явно оберіть модель рендерингу (CSR / SSR / SSG / islands) і зафіксуйте «чому» в ADR або README.
- Тримайте локальний стан локально; піднімайте і виносьте в контекст лише за реальної потреби.
- Заміряйте LCP, INP, CLS на production-like збірці, не лише локально.
- Тестуйте throttling мережі (Slow 3G) і слабкі пристрої — емулятор недостатній.
- Стежте за розміром чанків і lazy-loading маршрутів; один важкий імпорт відкочує оптимізації.
- Читайте документацію платформи (MDN, web.dev), а не лише API фреймворка.
Підсумок
Матеріал на Dev.to — нагадування, що фронтенд — це не «проста сторона» fullstack, а зона, де сходяться UX, мережа, платформа й архітектура. ШІ допомагає писати код швидше, але прогалину в базових знаннях він не закриє. Повний розбір — в оригіналі.