За последнее десятилетие одностраничные приложения (SPA) стали фактическим стандартом разработки сложных веб-приложений. Однако SPA не лишены своих проблем. Все большее число лидеров сообщества выступают за новое поколение приложений — интегрированное клиент-серверное решение, которое снижает зависимость от клиентского JavaScript и повышает скорость загрузки.

Две основные причины способствовали росту популярности SPA:

  1. Улучшение взаимодействия с пользователем. Традиционно взаимодействие с пользователем инициировало полное обновление страницы, что приводило к ухудшению пользовательского опыта. jQuery частично смягчил эти нарушения, перенеся определенные взаимодействия на сторону клиента, хотя часто это ограничивалось конкретными функциями.
  2. Расширенные возможности для разработчиков. Чтобы облегчить взаимодействие на стороне клиента, разработчикам пришлось создавать части сайта дважды: один раз на стороне сервера с использованием таких языков, как PHP, и один раз на стороне клиента для создания нового контента на основе данных пользователя. действия.

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

Однако по мере того, как эти приложения усложнялись, увеличивалось и время их загрузки. Это неразрывно связано со структурой SPA. Прежде чем пользователи смогут взаимодействовать с веб-приложением, браузеры должны сначала загрузить пакет JavaScript, скомпилировать его и запустить механизм шаблонов для создания HTML.

Чтобы решить эту проблему, разработчики представили серверный рендеринг (SSR). При использовании SSR сервер создает статическую страницу, что позволяет быстро выполнить первоначальный рендеринг приложения. Затем браузер загружает пакеты JavaScript и участвует в процессе, известном как «гидратация», который по существу повторно отображает страницу, наполняя ее интерактивностью.

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

Или мы так думали. За кулисами разработчики обдумывали способы трансформации подхода к разработке одностраничных приложений.

На недавней конференции Remix Дэн Абрамов, главный голос команды React, представил доклад под названием React from Another Dimension. В нем он визуализирует React как серверную библиотеку. Это не означает, что React станет строго серверным, но это намекает на то, в каком направлении, по мнению команды React, движется индустрия: перенесение задач обратно на сервер для увеличения времени загрузки.

Реагировать

Решение React состоит из двух компонентов, оба из которых доступны через Next.js:

Компоненты сервера

Серверные компоненты — это оптимизированные неинтерактивные версии существующих компонентов React, отображаемые исключительно на сервере. Без интерактивного аспекта React не нужно их увлажнять.

Диаграмма из документации Next.js демонстрирует сильные стороны серверных компонентов, которые в основном используются в качестве контейнеров для получения данных, отображения статического контента и загрузки интерактивных подкомпонентов.

Использование серверных компонентов дает два основных преимущества:

Вызовы API сервера. Выполняемые непосредственно серверными компонентами, они часто оказываются быстрее и упрощают традиционную последовательность загрузки, когда мы сначала инициируем компонент, вызываем API для его заполнения, а затем загружаем его дочерние компоненты.

Меньшие размеры пакетов. Пакет JavaScript становится более компактным за счет исключения серверных компонентов и минимизации их зависимостей. Поэтому использование таких утилит, как Lodash или Date-fns, не приведет к раздуванию наших пакетов. Крайне важно признать, что серверные компоненты React не являются новаторской идеей. Их создание датируется еще в 2020 году, и теперь они доступны через такие платформы, как Next.js.

Действия сервера

Next.js представляет новую экспериментальную функцию под названием действия сервера, которая упрощает операции изменения данных без использования JavaScript.

Этот механизм опирается на существующий атрибут действия в формах HTML. Вместо назначения URL-адреса он использует серверные методы. Каждый раз, когда вызывается метод сервера, Next.js создает новую конечную точку API, заменяя метод его URL-адресом, который принимает данные формы.

Будучи частью стандарта HTML, отправка форм может происходить до гидратации страницы. Удивительно, но эти формы вообще не требуют использования JavaScript.

То же самое обоснование может распространяться и на рендеринг на стороне клиента, позволяя React определять приоритетность гидратации этих конкретных методов при взаимодействии с пользователем.

В последующей теме в Твиттере Эндрю Кларк, член основной команды React, углубился в стратегию React в отношении действий с формами, предположив, что «скоро мы будем рекомендовать всем приложениям React отдавать предпочтение action обработчикам событий, таким как onClick».

Вероятно, потенциал серверных действий и компонентов является причиной того, что новый сайт документации React поддерживает React в рамках полнофункциональной структуры. Это предоставляет разработчикам множество новых серверных возможностей.

Но React и Next.js не являются игроками-одиночками. Remix, альтернатива Next.js, представляет уникальный подход к мутациям данных, а Nuxt, известный фреймворк Vue.js, запустил свою экспериментальную версию серверного компонента.

Квик

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

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

Когда пользователи взаимодействуют с приложением, Qwik отображает и гидратирует дополнительные компоненты по мере необходимости.

Выступая за инкрементный рендеринг, Qwik отдает приоритет начальному времени загрузки, отображая только то, что жизненно важно, и постепенно усиливая интерактивность приложения при взаимодействии с пользователем. Следовательно, эта тактика повышает производительность и реактивность, что приводит к более гибкому пользовательскому опыту.

Эти примеры сигнализируют о растущей тенденции признания ограничений рендеринга на стороне клиента. Новая парадигма выступает за более комплексную структуру стека, способствуя более тесной связи клиент-сервер.

Еще неизвестно, смогут ли такие библиотеки, как React, опирающиеся на сторонние фреймворки, такие как Next.js, сохранить свое преимущество перед такими фреймворками, как Qwik, которые построены на основе этой новой парадигмы.

Оригинально опубликовано на сайте https://semaphoreci.com 23 августа 2023 г.