Одной из наиболее динамично развивающихся областей разработки программного обеспечения сегодня является интерфейсная архитектура. Некоторые новаторы продвигают современные технологии для разработки более мощных способов создания динамических пользовательских интерфейсов. Большая часть этой работы происходит в бешеном темпе и прямо под открытым небом.
Благодаря ряду проектов JavaScript с открытым исходным кодом, таких как SvelteKit, Solid, React, Qwik и Astro, мы имеем место в первом ряду в развитии будущего Интернета. Вот руководство к пониманию действия.
Что такое гидратация?
Большая часть деятельности по улучшению современной интерфейсной архитектуры сосредоточена на том, что называется гидратация. Чтобы понять, что такое гидратация и почему она занимает центральное место в современной интерфейсной архитектуре, давайте разберемся с концепциями высокого уровня. Чтобы обеспечить чудо реактивности, каждая платформа должна учитывать три аспекта, показанных на диаграмме ниже.
ИДГАспекты высокого уровня реактивности.
Основной посыл диаграммы заключается в том, что фреймворк отвечает за формирование представления, сохранение состояния и управление взаимодействием между ними. (Если вы знакомы с шаблоном MVC, вы услышите его здесь.)
Как только эти три части будут на месте, можно приступать. Пользователь может видеть страницу и взаимодействовать с ней.
Наивный подход, или подход по умолчанию, заключается в том, чтобы просто взять все, что нужно клиенту — фрейм, реактивный код и состояние — и отправить его. Затем клиент (браузер) выполняет работу по отображению фрейма (то есть рисованию пользовательского интерфейса), интерпретации JavaScript и привязке состояния.
Этот подход обладает замечательным преимуществом простоты как для рабочего кода, так и для человеческого разума, пытающегося его понять. У этого также есть большой недостаток: первоначальный рендеринг страницы должен ждать всего, и пользователю приходится выдерживать все эти изменения в сети и браузере. Кроме того, если не принять меры, страница будет отображаться, а затем смущающе перестраиваться в окончательный макет. Нехороший вид.
Это вдохновило разработчиков попробовать сначала отрисовать начальную страницу на сервере (рендеринг на стороне сервера или SSR) и отправьте его. Затем у пользователя появляется достойная страница для просмотра, пока остальная часть кода и состояния отправляется и загружается. Это большое упрощение, но это основная идея.
Время, необходимое для создания базовой компоновки, называется первая содержательная краска (ФКП). Следующий этап, которого должна достичь страница, измеряется время интерактивного (TTI), то есть время, в течение которого пользователь сможет фактически использовать страницу.
Процесс создания начальной страницы и превращения ее в интерактивную, то есть гидратация.
Ограничения рендеринга на стороне сервера
Суть в том, что SSR имеет тенденцию улучшать FCP, но ухудшать TTI. Таким образом, целью стало достижение баланса между ними, максимизируя их обоих, сохраняя при этом приятный опыт разработчика (DX).
В попытках улучшить гидратацию были предложены, приняты, отвергнуты, модифицированы и объединены различные подходы. Как только начнешь изучать детали реализации, поразишься, насколько сложной она становится. Сбалансированное улучшение FCP и TTI с приличным DX? Звучит легко, но это не так.
Одна из причин сложности заключается в том, что мы находимся в процессе поиска всех компромиссов; это разворачивающаяся сцена. Однако как только путь вперед определится, мы должны ожидать двух результатов от возникающей клиентской архитектуры. Во-первых, он должен создавать веб-приложения, которые будут ощущаться как «следующее поколение», точно так же, как хорошо продуманные приложения сегодня обеспечивают немного, но явно лучший опыт, чем те, что были несколько лет назад.
Во-вторых, и, возможно, это даже более важно, наша улучшенная клиентская архитектура должна иметь далеко идущие последствия, помимо повышения производительности. Разбираясь в этой сложности и решая ее, фронтенд-инженеры придут к лучшей модели как для системы, так и для разума. Лучшая архитектура на самом деле представляет собой более мощную эвристику. Это приводит к последующим выгодам, которые часто непредсказуемы.
Вы можете увидеть это в действии на самой реактивности. Реактивность ворвалась на сцену, потому что она предлагала способ перегрузить привязку состояния от мозга разработчика к фреймворку. Но на этом преимущества не закончились. Архитектура стала не только проще, но и логичнее. Это суммарное повышение производительности и функциональности по всем направлениям.
Поскольку современные платформы JavaScript включают в себя как сервер, так и клиент, результаты этих разработок могут иметь серьезные последствия для архитектуры приложений в целом.
Подходы к улучшению гидратации
Основной способ улучшить ситуацию с гидратацией – это смотреть на вещи более детально. Разбив представление, интерактивность и состояние на более мелкие части, мы можем загружать и активировать их поэтапно, оптимизированные для FCP и TTI. Вот обзор некоторых подходов.
Полный отказ от JavaScript
Один из подходов, который был принят в передовой практике, — это анализ сайтов на наличие тех страниц, которые вообще не требуют JavaScript. Это относится к новому понятию многостраничные приложения (МПА). Это своего рода золотая середина между одностраничными приложениями (SPA) и прямой постраничной навигацией (поведение в Интернете по умолчанию). Идея здесь состоит в том, чтобы найти части приложения, которые можно сразу же отправить в виде HTML и ресурсов, что приведет к наилучшему SEO и времени загрузки.
Подход без JS можно увидеть, например, в SvelteKit. Конечно, это ничего не делает для тех страниц, которые требуют реактивного взаимодействия. Фреймворки по-прежнему должны обеспечивать гидратацию на тех страницах, которые действуют как SPA.
Островная архитектура
Астро поддержал идею островная архитектура. Идея состоит в том, чтобы определить, какие части страницы являются статическими, а какие требуют реактивности. Обладая этими знаниями, вы можете точно настроить загрузку страницы, полностью игнорируя содержимое фрейма, которое никогда не меняется, а затем загружая другие части (острова) только по мере необходимости.
При понимании этой идеи полезно отметить, что она направлена на улучшение SPA. Другими словами, весь статический контент, который вы идентифицируете, может просто находиться там, выполняя свою работу без какого-либо снижения производительности. Все состояние и навигация на стороне клиента сохраняются.
С другой стороны, этот подход позволяет вам откладывать загрузку каждого острова до тех пор, пока что-то не сделает это необходимым (например, прокрутка в поле зрения или щелчок мышью). Минусом является то, что на практике это часто приводит к нагрузкам, возникающим в особо неподходящий момент (как раз когда пользователь что-то делает).
Лениво загружаемые границы
Такие функции, как компонент React Suspense, предлагают подход, который сохраняет базовую модель гидратации на месте, но разлагает ее по границам, которые затем загружаются отложенно. Преимущество этого подхода состоит в том, что большая часть знакомого процесса сохраняется, но есть и обратная сторона: для достижения хороших результатов от разработчика требуется много размышлений и настроек. Мысленно разработчик находится в состоянии соединить мир компоновки компонентов и разделения кода во время сборки.
Более того, отложенная загрузка может помочь только в той мере, в какой большая часть инфраструктуры все еще должна быть отправлена заранее.
Возобновляемость
Возобновляемость — это идея, предложенная инфраструктурой Qwik. Qwik глубже погружается в элементы приложения и создает между ними ленивые границы. (В каком-то смысле это можно рассматривать как весьма сложную форму отложенной загрузки границ.) Возобновляемость означает, что клиент может продолжить работу с того места, на котором остановился сервер, и поддерживать детальную синхронизацию.
Компоненты сервера
React реализует идею серверных компонентов и связанное с этим улучшение производительности, называемое потоковой передачей. Вот описание того, как работают серверные компоненты. По сути, серверные компоненты позволяют вам определить, какие части приложения могут быть полностью запущены на сервере, тем самым избегая каких-либо штрафов за рендеринг на стороне клиента.
Потоковое вещание
Потоковая передача — еще одна развивающаяся техника React, связанная с приостановкой. Идея здесь состоит в том, чтобы позволить начать отправку контента, такого как HTML, клиенту еще до того, как все необходимые данные будут готовы на сервере. Затем это можно применять при возникновении взаимодействия компонентов.
Частичная гидратация или прогрессивная гидратация
С этими терминами все становится немного мутно. Astro описывает архитектуру своего острова как частичная гидратация. Проще говоря, одновременно гидратируются только определенные элементы страницы. Это еще иногда называют прогрессивная гидратация. Оба эти термина иногда применяются к другим методам.
На самом деле у нас здесь есть три термина, наступающих друг другу на пятки: островной, частичный, прогрессивный. Неважно, основная идея та же: нам нужно разложить структуру приложения на более мелкие части, чтобы оно загружалось более разумно.
Разделенная гидратация?
Попробуем немного распутать термины. Допустим, островная архитектура относится к фрагментам независимой интерактивности в стиле Astro в статическом кадре.
Двигаясь выше, можно сказать, что вся идея разложения пользовательского интерфейса — это частичная гидратация, и острова Астро — один из примеров этого. Однако мы не можем сделать это без риска, потому что Astro == Island == Partial уже плавает там. Также, частичный кажется, предполагает неполное состояние гидратации, что вводит в заблуждение.
Затем снова, прогрессивный вызывает путаницу с прогрессивными веб-приложениями (PWA). Может быть разделенная гидратация это хороший термин для обозначения всеобъемлющей идеи.
Эволюция архитектуры внешнего интерфейса
Активность вокруг архитектуры внешнего интерфейса JavaScript привела к созданию одних из самых интересных кодовых работ, которые я когда-либо видел. Это пространство, полное увлеченных людей, которые исследуют новую концептуальную территорию и создают новаторские программы для этого. И они взаимодействуют и делятся своими идеями открыто и совместно. Приятно смотреть.
Среди этих людей — Райан Карниато (Солид) и Миско Хевери (Квик). Оба продвигают новейшие достижения, по мере продвижения выпуская код и информацию для остального мира. Два хороших места для начала работы Карнатио — здесь и здесь, а два — для Хевери здесь и здесь. здесь.
