Мир веб-разработки провел большую часть десятилетия, убеждая себя в том, что браузер должен брать на себя основную нагрузку. Мы начинали с документов и форм, а затем постепенно переносили каждую мыслимую операцию на сторону клиента. Маршрутизация, управление состоянием, получение данных, логика рендеринга и даже оркестрация запросов к базе данных через GraphQL — всё это переместилось в JavaScript-бандлы, которые становились всё тяжелее с каждым релизом. Фреймворки множились, конвейеры сборки усложнялись, и то, что начиналось как способ сделать приложения отзывчивыми, превратилось в архитектуру, где страница не может отрисовать ни одного значимого пикселя, пока не будут загружены, распарсены и выполнены мегабайты кода.
Этот сдвиг решил реальные проблемы. Страницы с серверным рендерингом и щепоткой jQuery с трудом обеспечивали плавные, похожие на приложения переходы, которых ожидали пользователи. Одностраничные приложения (SPA) дали нам мгновенную навигацию, постоянное состояние и насыщенное взаимодействие. Но цена росла. Теперь команды управляют сложными хранилищами состояния на стороне клиента, сражаются с массивными JavaScript-бандлами, поддерживают капризные слои синхронизации данных и отлаживают конвейеры сборки, которые порой кажутся полноценной работой. Мы обменяли один набор проблем на другой, и многие разработчики теперь задаются вопросом: действительно ли каждому приложению нужно платить этот налог?
Два события делают ответ на этот вопрос проще.
HTMX и возвращение гипермедиа
Первое — это HTMX. На первый взгляд это кажется небольшой библиотекой, но её архитектурное значение огромно. HTMX рассматривает HTML как нативный формат для логики приложения, а не как статическую оболочку, которую необходимо «наполнять» с помощью JavaScript.
Вот что меняется на практике. Традиционно, когда пользователь нажимает кнопку, чтобы загрузить больше комментариев, фронтенд отправляет запрос fetch, получает JSON-пакет, нормализует его в хранилище на стороне клиента, пропускает через шаблон компонента, сравнивает виртуальный DOM и, наконец, вносит изменения на страницу. HTMX сокращает эту цепочку. Сама кнопка содержит атрибуты, которые говорят браузеру, куда отправить запрос и какой элемент страницы заменить. Сервер возвращает фрагмент HTML — только новые комментарии, обернутые в div. Браузер просто подставляет его. Здесь нет JSON, нет дерева состояния фронтенда, нет алгоритма согласования (reconciliation) и нет императивного JavaScript для синхронизации интерфейса с сервером.
Это не отказ от современной разработки. Это отказ от излишних абстракций. HTMX доказывает, что гипермедиа — архитектурный стиль, на котором держался ранний веб, — всё еще может поддерживать сложные интерфейсы при использовании современной эргономики. Любой элемент может инициировать запросы, а не только формы и ссылки. Любое событие может вызвать обновление. Сервер остается источником истины (source of truth) как для данных, так и для представления.
Декларативные частичные обновления Chrome
Второй сдвиг более свежий и происходит внутри самого браузера. Chrome внедряет Declarative Partial Updates, или DPU. Эта функция позволяет браузеру стримить HTML и вставлять его напрямую в целевые части страницы по мере поступления байтов.
До появления DPU, если вы хотели транслировать живые данные на веб-страницу, вам обычно приходилось использовать WebSockets, Server-Sent Events или long-polling в сочетании с ручным манипулированием DOM. Фронтенд должен был управлять соединением, парсить полезную нагрузку и решать, как именно и куда внедрять разметку. DPU меняет уравнение, делая процесс декларативным. Разработчик указывает целевой контейнер, а браузер берет остальное на себя: получает поток, парсит фрагмент и помещает его именно туда, где он должен быть, даже до того, как полный ответ будет завершен.
Представьте себе панель мониторинга, отображающую серверные логи, или очередь поддержки, обновляющуюся в реальном времени. С DPU бэкенд отправляет простые фрагменты HTML по мере их генерации. Браузер стримит их в тело таблицы или контейнер ленты без единой строки логики стриминга на стороне клиента. Сборка происходит нативно.
Модель Server-First
Объедините HTMX и DPU, и вы получите целостную архитектуру, где сервер владеет состоянием и генерирует UI, а браузер отвечает за отображение и ввод данных пользователем. Бэкенд-фреймворки, такие как Rails, Laravel, Django, шаблоны Go или ASP.NET, снова становятся основным уровнем интерфейса. Фронтенд — это не отдельное приложение, потребляющее API. Это гипермедиа-интерфейс, который создает сервер.
Эта модель подходит удивительно широкому спектру программного обеспечения. Рассмотрим типичное SaaS-приложение. Это дашборды с сортируемыми таблицами. Это панели администратора с формами и фильтрами. Это внутренние инструменты, которые переводят записи из одного состояния в другое. Это CRUD-процессы, которые отображают список, предоставляют детальный просмотр и позволяют пользователю редактировать поля. Это даже интерфейсы ИИ, где языковая модель потоково передает токены пользователю, и каждый токен или абзац может быть обернут в HTML и добавлен в ветку диалога. Для всех этих задач «толстый» JavaScript-клиент часто является избыточным.
Преимущества очевидны и практичны. Первая загрузка страницы происходит быстрее, так как первая значимая отрисовка (first meaningful paint) приходит в виде HTML, а не после завершения цикла гидратации. Объем передаваемого JavaScript уменьшается, так как не нужно доставлять virtual DOM, клиентский роутер и библиотеку управления состоянием. Поисковые системы видят полный контент без выполнения бандлов, поэтому SEO работает по умолчанию. Сложность снижается, так как одна кодовая база отвечает за роутинг, бизнес-логику и рендеринг. Отладка становится проще. Если что-то выглядит не так, вы проверяете вкладку Network и видите именно тот HTML, который отправил сервер. Нет непрозрачного объекта состояния на стороне клиента, который нужно подвергать реверс-инжинирингу.
А как же React и тяжелые клиенты?
Это вовсе не означает, что React мертв или что SPA — это ошибка. Сложным приложениям уровня редакторов все еще нужен «толстый» клиент. Figma запускает движок на C++, скомпилированный в WebAssembly, прямо в браузере, потому что задержки при запросах к серверу сделали бы рисование невозможным. Canva манипулирует холстом (canvas) со скоростью шестьдесят кадров в секунду, используя геометрию на стороне клиента. Google Docs использует операционные преобразования (operational transforms), чтобы разрешать конфликты редактирования за миллисекунды. Эти инструменты по сути являются десктопными приложениями, работающими во вкладке браузера. Они не вернутся к формам, рендерируемым на сервере.
Но большинство программ — это не Figma. Большинство программ — это не графические редакторы реального времени. Большинство программ — это экраны отчетности, панели конфигурации, процессы бронирования или формы управления контентом. Для этого «длинного хвоста» приложений отправка сотен килобайт JavaScript-фреймворка только ради того, чтобы переключить модальное окно или получить список записей, никогда не имела особого смысла. Экономика стека меняется. Мы заново открываем для себя, что благодаря edge-вычислениям сервер может быть близок к пользователю, а сам браузер стал достаточно мощным, чтобы обновлять фрагменты без участия фреймворка в каждом байте.
Маятник находит баланс
Дуга веб-архитектуры качается обратно в сторону простоты, но это не наивное возвращение в девяностые. Браузер становится умнее. Такие функции, как DPU, не заменяют изобретательность разработчиков; они поглощают паттерны, которые мы раньше реализовывали вручную — потоковую передачу, частичные обновления, целевую вставку в DOM — и интегрируют их в саму платформу. HTMX дает нам словарь для выражения этих моделей поведения без необходимости воссоздавать миниатюрную операционную систему на фронтенде.
Вам больше не нужно выбирать между простой архитектурой и отзывчивым пользовательским интерфейсом. Можно получить и то, и другое. Сервер может управлять интерфейсом, браузер — собирать его, а JavaScript, который вы пишете, может быть сосредоточен на подлинной интерактивности, а не на «инфраструктурной обвязке».
Для следующего поколения дашбордов, инструментов администрирования и интерфейсов на базе ИИ самым умным клиентом может оказаться тот, который делает меньше.