5.6 Фронтенд-разработка

Обзор и мотивация

Фронтенд-разработка это дисциплина построения клиентского слоя программ: кода, работающего в браузере или на устройстве и превращающего дизайн, содержимое и данные в работающий интерфейс. Она охватывает выбор фреймворка и архитектуры, стратегию отрисовки, управление состоянием, производительность и устойчивость в огромном разнообразии браузеров, устройств и сетевых условий реального мира. Фронтенд это место, где вся работа выше по течению (UX, дизайн, контент, доступность, интернационализация) либо успешно достигает пользователя, либо рассыпается.

Для больших команд фронтенд уникально труден, потому что он подвержен среде, которую организация не контролирует. Браузеры, устройства, соединения и настройки пользователей сильно различаются, а платформа (веб) эволюционирует непрерывно. В масштабе архитектурные выборы накапливаются. Фреймворк, выбранный сегодня, ограничивает найм, производительность и сопровождаемость на годы, а тысячи малых решений о размере сборки и отрисовке складываются в тот опыт, который пользователи действительно получают. Общие стандарты, библиотеки компонентов, бюджеты производительности и архитектурные шаблоны то, что не даёт многим независимым командам произвести медленное, непоследовательное, хрупкое целое.

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

Ключевые принципы

Фронтенд работает в среде, которую вы не контролируете; проектируйте под изменчивость и отказ.
Выбирайте скучную долговечную технологию для долгоживущих систем; оптимизируйте под сопровождаемость и найм.
Производительность это функция и для многих пользователей предпосылка доступа.
Прогрессивное улучшение: сначала доставляйте работающий основной опыт, затем наслаивайте улучшения.
Отправляйте меньше кода; самый быстрый и надёжный код тот, который вы не поставляете.
Подбирайте стратегию отрисовки под тип содержимого и потребность пользователя, а не моду.
Устойчивость: интерфейс должен деградировать изящно, а не ломаться, когда что-то идёт не так.
Стандарты и возможности платформы переживают фреймворки; опирайтесь на платформу.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
Популярный зрелый фреймворк	Большой пул специалистов, стабилен, поддерживается	Может нести груз наследия; медленнее принимает новейшие функции
Новейший фреймворк	Современные функции, выигрыш в производительности	Риск оттока, малый пул специалистов, неопределённая долговечность
SSR / SSG	Быстрая первая отрисовка, SEO, работает без JS	Сложность сервера или сборки, трудности кэширования
CSR (SPA)	Богатая интерактивность, ощущение приложения	Медленная первая загрузка, зависимость от JS, цена SEO и устойчивости
Тяжёлый клиентский JavaScript	Богатые функции	Плохая производительность на маломощных устройствах, хрупко
Прогрессивное улучшение	Устойчиво, инклюзивно, работает везде	Больше проектных усилий на определение рабочей базы
Микрофронтенды	Независимые развёртывания команд, масштаб	Сложность, дублированные зависимости, накладные расходы производительности

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

Вопросы для обсуждения с командой

Как мы изолируем специфичный для фреймворка код, чтобы приложение не было заложником жизненного цикла одной библиотеки? Для долгоживущих корпоративных и государственных систем отток фреймворков крупнейшая избегаемая трата: перепись дорога и рискованна, а библиотека, трендовая сегодня, ограничивает найм и сопровождение на годы. Опора на веб-стандарты и размещение специфичного для фреймворка кода за ясными границами означает, что ваша бизнес-логика и содержимое переживут следующую смену фреймворка. Решите, где эти швы и мог бы ли новый инженер отличить код платформы от кода фреймворка. Принесите оценку цены вашей последней миграции фреймворка или цены той, что маячит. Если ваша основная логика приварена к API одной библиотеки, оцените эту сцепку, прежде чем защищать выбор фреймворка.
Подбираем ли мы стратегию отрисовки по маршрутам или навязываем одну стратегию всему продукту? Отрисовка на стороне сервера даёт быструю первую отрисовку и работает без клиентского JavaScript для публичного содержимого, статическая генерация максимизирует скорость для редко меняющихся страниц, а отрисовка на клиенте подходит интерактивным поверхностям, похожим на приложение, за входом. Навязывание одной глобально либо замедляет публичные страницы тяжёлым JavaScript, либо чрезмерно проектирует простую страницу содержимого. Для государства это вопрос охвата, где услуга, работающая только после загрузки большой сборки, исключает пользователей на старых устройствах и медленных соединениях. Принесите ваши ключевые маршруты и пометьте каждый стратегией, которую он реально использует сегодня. Если публичной странице нужен JavaScript, чтобы показать содержимое, решите, намеренный ли это выбор или случайность.
Насколько дисциплинировано наше управление состоянием и не сверхцентрализуем ли мы всё в одном тяжёлом глобальном хранилище? Раздельное хранение серверного состояния, состояния URL и локального состояния UI предотвращает сцепление и штормы повторной отрисовки, делающие большие фронтенды медленными и хрупкими, однако соблазнительное умолчание свалить всё в одно глобальное хранилище. Это накапливается в масштабе, где многие команды, касающиеся одного общего хранилища, создают скрытые зависимости и непредсказуемую производительность. Договоритесь, где принадлежит каждый вид состояния и что не принадлежит глобальному хранилищу. Принесите компонент, перерисовывающийся больше, чем следует, и проследите почему. Если ответ раздутое центральное хранилище, решите границы, пока сцепление не затвердело.
Каковы наши бюджеты производительности, валят ли они сборку в CI и измеряются ли на устройствах, которые у наших пользователей действительно есть? Бюджет, который никто не принуждает, пожелание, а бюджет, измеренный только на быстрых ноутбуках команды, описывает пользователя, которого не существует. Для большой организации бюджеты единственный механизм, держащий размер сборки и Core Web Vitals в узде, пока десятки команд добавляют функции на общую поверхность, потому что ни один рецензент не поймает глазом каждую регрессию. Конкурирующее давление скорость поставки: жёсткий отказ сборки из-за нескольких килобайт кажется препятствием, пока не оценишь отток, который он предотвращает. Принесите ваши текущие бюджеты, данные мониторинга реальных пользователей с маломощных устройств и медленных соединений и список выпусков, где регрессия проскользнула. В государстве, где мандат обслуживать всё общество, включая людей на старых телефонах и платном трафике, привяжите бюджет к самой медленной десятой части пользователей, а не медиане, и сделайте барьер CI не подлежащим обсуждению.
Какие наши сервисы должны продолжать работать без клиентского JavaScript и тестировали ли мы этот путь на самом деле? Прогрессивное улучшение легко заявить и легко тихо сломать, потому что улучшенный путь тот, которым разработчики пользуются каждый день, а база гниёт нетестированной. Решать это намеренно важно в масштабе, поскольку многие команды, поставляющие на одну платформу, будут предполагать, что скрипты всегда загружаются, пока общий стандарт не скажет иначе, а одна жёсткая зависимость может сломать основную задачу для любого, у кого сборка не загрузилась. Компромисс реален: рабочая база без JavaScript стоит проектных усилий и ограничивает то, как вы строите интерактивность. Принесите ваши критичные пути пользователей, тест, загружающий каждый с отключёнными или упавшими скриптами, и свидетельства того, как часто скрипты действительно не загружаются в поле. Для государственной услуги форма пособия или налога, рушащаяся, когда один скрипт истекает по времени, не деградированный опыт, а гражданин, не способный выполнить юридическое обязательство, поэтому воспринимайте базу как требование соответствия, а не любезность.
Когда микрофронтенды по-настоящему окупают свою сложность и кто решает, прежде чем команда потянется к ним? Независимые развёртывания команд привлекательны, но микрофронтенды несут сложность распределённой системы, дублированные зависимости и налог на производительность, который пользователи платят более медленными загрузками. Без общей точки принятия решений амбициозные команды принимают их ради организационного удобства задолго до того, как масштаб оправдывает цену, и весь продукт наследует накладные расходы. Конкурирующее соображение автономия: команды, поставляющие на одной общей кодовой базе, могут блокировать друг друга, а в подлинном масштабе эта сцепка сама дорогая проблема. Принесите число команд, касающихся поверхности, борьбу за развёртывание, которую вы реально испытываете сегодня, и измеренную оценку дублирования полезной нагрузки, которое внесло бы разделение. Для корпоративных и государственных платформ, где архитектурные решения связывают многие команды на годы и должны пережить аудит и передачу, требуйте явного документированного порога и владельца, утверждающего переход, а не позволяйте каждой команде решать изолированно.

Взгляд по секторам

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

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

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

Государственный сектор. Вы обслуживаете всё общество, включая людей на старых устройствах, с медленными или платными по трафику соединениями и со вспомогательными технологиями, поэтому прогрессивное улучшение и производительность обязательства, а не лоск. Сделайте рабочую базу без JavaScript жёстким правилом для услуг, обращённых к гражданам, бюджетируйте страницы на самых медленных пользователей, а не медиану, и держите основную задачу выполнимой, когда скрипт отказывает. Применимы закупки и прозрачность: отдавайте предпочтение долговечной технологии, склоняющейся к стандартам и избегающей привязки к единственному поставщику, документируйте требования доступности и производительности в контрактах и умейте показать, что услуга работает для наименее обеспеченного пользователя, а не только для демонстрационного устройства.

Примеры

Стартап. Стартап посевной стадии был искушён построить маркетинговый сайт и поток регистрации как тяжёлое одностраничное приложение, но его целевые клиенты были покупателями, нередко на телефонах среднего уровня по нестабильной мобильной связи. Два основателя вместо этого отрисовали публичные страницы на сервере, чтобы они быстро загружались и работали до запуска любого JavaScript, и оставили клиентскую интерактивность для приложения за входом. Они задали простой бюджет размера сборки в CI, чтобы небрежная зависимость не могла тихо раздуть страницу. Лёгкая быстрая первая загрузка измеримо улучшила регистрации, а опора на веб-стандарты держала их небольшую кодовую базу лёгкой для сопровождения по мере найма.

Крупная организация. Фирма финансовых услуг модернизировала разросшийся набор внутренних и клиентских приложений, стандартизировавшись на зрелом фреймворке, общей библиотеке компонентов и принудительных бюджетах производительности в CI. Стратегия отрисовки выбиралась по поверхности: отрисованные на сервере кэшируемые страницы для публичного маркетинга и содержимого и клиентски отрисованное приложение за входом для интерактивных панелей. Бюджеты сборки и мониторинг реальных пользователей ловили регрессии до выпуска, держа время загрузки быстрым по многим командам фирмы и снижая риск оттока фреймворков, ранее вынуждавший к дорогим переписям.

Государственный сектор. Команда национальной цифровой службы построила услуги для граждан с прогрессивным улучшением как жёстким правилом: каждая услуга работает сначала на семантическом HTML и отрисовке на сервере, а JavaScript лишь улучшает. Это гарантирует, что услуга работает на старых телефонах, медленных сельских соединениях и вспомогательных технологиях, на группах населения, которых государство не может исключить. Бюджеты производительности держат страницы лёгкими и быстрыми на маломощных устройствах, а изящная деградация означает, что упавший скрипт никогда не мешает кому-либо завершить заявление на пособие. Результат услуга быстрая, устойчивая, доступная и пригодная для всего общества.

Бизнес-обоснование: мотивы, ROI и TCO

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

По TCO стоимость принятия это дисциплина бюджетов производительности и тестирования, усилия прогрессивного улучшения и вложения в общие инструменты и библиотеки компонентов. Цена непринятия платится в медленном опыте, теряющем пользователей и выручку, исключении пользователей маломощных устройств и вспомогательных технологий (с юридической экспозицией в государстве), хрупких приложениях, ломающихся в поле, и дорогом оттоке фреймворков и переписях, вызванных погоней за трендами. Проблемы фронтенда проявляются как рассеянный отток и нагрузка на поддержку, а не единая строка расходов, поэтому легко недоинвестировать.

Чтобы обосновать это перед руководством, свяжите Core Web Vitals и время загрузки с воронками конверсии и завершения, выразите числами пользователей, исключённых тяжёлыми клиентскими подходами, и оцените цену прошлых или маячащих переписей против стабильности долговечной архитектуры, склоняющейся к стандартам. Формулируйте бюджеты производительности и прогрессивное улучшение как снижение риска и расширение охвата.

Антипаттерны и ловушки

Погоня за фреймворками: перепись на новейшую библиотеку, вносящая отток без выгоды пользователям.
Опыт только на JavaScript: ничего не работает, пока не загрузится и не запустится большая сборка, исключая многих пользователей.
Тестирование только на быстрых устройствах: флагманские ноутбуки команды скрывают реальный пользовательский опыт.
Игнорирование размера сборки: неограниченный рост зависимостей, пока страницы не станут медленными везде.
Нет бюджета производительности: регрессии молча накапливаются выпуск за выпуском.
Отказы с пустым экраном: нет состояний загрузки, пустоты, ошибки или офлайна; упавший запрос ломает страницу.
Сверхцентрализованное глобальное состояние: всё в одном хранилище, создающем сцепление и штормы перерисовки.
Преждевременные микрофронтенды: сложность распределённой системы и дублированные полезные нагрузки без масштаба, который их оправдал бы.
Пренебрежение доступностью и i18n в архитектуре: прикручивание их позже по высокой цене.

Модель зрелости

Уровень 1: Начальный. Стихийный фронтенд на команду без общих стандартов. Тяжёлый клиентский код, нет бюджетов производительности, тестирование только на собственных устройствах команды. Выбор фреймворков по предпочтению или шуму, а упавший скрипт может оставить пользователей смотреть на пустой экран.

Уровень 2: Развитие. Некоторые команды принимают общие инструменты и библиотеку компонентов, но практика непоследовательна по организации. Производительность измеряется время от времени, а не бюджетируется или принуждается. Стратегия отрисовки нередко единая независимо от типа содержимого, а тестирование на разных устройствах ограничено и ручное.

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

Уровень 4: Управление. Фронтенд измеряется и контролируется данными. Бюджеты производительности принуждаются в CI, так что регрессии валят сборку, а Core Web Vitals отслеживаются мониторингом реальных пользователей с настоящих маломощных устройств и медленных соединений относительно явных базовых значений. Размер сборки, покрытие состояниями ошибок и офлайна и доля пользователей, обслуживаемых на самых медленных соединениях, сообщаются и пересматриваются, так что решения опираются на свидетельства, а не мнение.

Уровень 5: Оркестрация. Производительность, устойчивость и охват непрерывно улучшаются и привязаны к бизнес-результатам по всей организации. Фронтенд опирается на веб-стандарты ради долговечности, изолирует зависимости от фреймворков, чтобы миграции были дёшевы, и эволюционирует архитектурно адаптивно по мере сдвигов устройств, платформы и данных реальных пользователей. Всё общество и все устройства первоклассны, а практика фронтенда интегрирована с дизайном, доступностью и планированием продукта, а не воспринимается как отдельная забота.

Идеи для обсуждения

Как решить, когда миграция фреймворка стоит своей цены и риска?
Какие Core Web Vitals и бюджеты сборки должны быть жёсткими порогами, валящими сборку?
Где прогрессивное улучшение необходимо, а где приемлемо клиентское приложение?
Как держать архитектуру фронтенда согласованной по многим автономным командам?
Когда микрофронтенды по-настоящему окупают свою сложность?
Как следует встроить тестирование на реальных устройствах и медленных сетях в конвейер?

Главные выводы

Фронтенд работает в среде, которую вы не контролируете: проектируйте под изменчивость и отказ.
Выбирайте долговечную хорошо поддерживаемую технологию для долгоживущих систем; опирайтесь на веб-стандарты.
Подбирайте стратегию отрисовки (SSR, SSG, CSR, потоковая) под содержимое и потребность, нередко смешивая по маршрутам.
Воспринимайте производительность как бюджетируемую измеряемую дисциплину, принуждаемую в CI данными реальных пользователей.
Стройте с прогрессивным улучшением, чтобы основной опыт работал везде.
Отправляйте меньше JavaScript; разделяйте код, лениво загружайте и предпочитайте возможности платформы.
Особенно для государства производительность и устойчивость предпосылки равного доступа.

Источники и дополнительное чтение

Jeremy Keith, Resilient Web Design
Aaron Gustafson, Adaptive Web Design (progressive enhancement)
Steve Souders, High Performance Web Sites
Ilya Grigorik, High Performance Browser Networking
Addy Osmani, writings on performance, code-splitting, and the cost of JavaScript
Google, Web Vitals and web.dev performance guidance
MDN Web Docs, web platform and progressive enhancement references
Alex Russell, essays on the cost of JavaScript and device diversity
UK Government Digital Service, progressive enhancement and frontend guidance
WHATWG HTML Living Standard and W3C web platform specifications

5.6 Фронтенд-разработка

Обзор и мотивация

Ключевые принципы

Рекомендации

Выбирайте фреймворки по долговечности и пригодности, а не по шуму

Подбирайте стратегию отрисовки под потребность

Воспринимайте производительность как бюджетируемую измеряемую дисциплину

Стройте с прогрессивным улучшением и устойчивостью

Обеспечьте совместимость между браузерами, устройствами и вспомогательными технологиями

Управляйте фронтендом как общей инфраструктурой