Сравнительный анализ подходов к реактивному рендерингу пользовательских интерфейсов: проприетарные механизмы и стандарт TC39 signals

Введение

За последнее десятилетие клиентские веб-приложения заметно усложнились. Современные интерфейсы обязаны мгновенно реагировать на действия пользователя, синхронизировать состояние между множеством компонентов и эффективно управлять обновлениями DOM.

Индустрия ответила появлением реактивных JavaScript-фреймворков - React, Vue, Angular, Svelte, Solid.js - каждый из которых реализует собственный механизм отслеживания изменений и обновления интерфейса [1; 2].

Широкое распространение этих инструментов выявило структурный изъян экосистемы.

Реактивность каждого фреймворка закрыта и несовместима с остальными: реализации одной и той же задачи дублируются, компоненты не переносимы между экосистемами, а зависимость от инструментальной цепочки сборки нередко оказывается чрезмерной. Для крупных продуктов подобные издержки терпимы. Но для проектов, где критичны минимальный размер дистрибутива и работа без этапа компиляции - встроенных виджетов, статических сайтов с интерактивными элементами - существующие решения либо избыточны по объёму, либо по-прежнему навязывают собственный закрытый механизм [3; 4].

В 2024 году комитет по стандартизации JavaScript (Ecma TC39) вынес на рассмотрение предложение Signals - набор реактивных прими- тивов, встраиваемых непосредственно в спецификацию языка [5]. Р. Айзенберг, один из авторов предложения, подчеркивает, что стандартизация позволит фреймворкам совместно использовать единый реактивный слой вместо того, чтобы каждый поставлял собственный - что сделает их компактнее и быстрее [6]. Уже сейчас доступна эталонная программная реализация - полифилл - позволяющая использовать предложенный API до его появления в браузерах. Отсюда вопрос, которому посвящена настоящая работа: достаточны ли стандартизированные примитивы для построения конкурентоспособного фреймворка рендеринга? Эмпирического ответа на него в научной литературе пока нет. Цель исследования - сравнить существующие механизмы реактивного обновления интерфейсов и экспериментально проверить, могут ли примитивы TC39 Signals служить надежной основой минималистичного фреймворка.

Для достижения этой цели решаются следующие задачи:

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

2. Реализовать экспериментальный микро-фреймворк на основе TC39 signal-polyfill и сравнить его с пятью распространёнными решениями (React, Vue 3, Svelte, Solid.js, Alpine.js) по трём метрикам: размер дистрибутива, производительность DOM-операций, объем прикладного кода; 3. На основании полученных данных оценить, способны ли примитивы TC39 Signals стать основой фреймворка, конкурентного существующим решениям и не требующего инструментов сборки. Методология. В работе применены методы анализа и синтеза научной литературы, сравнительного анализа программных решений, а также экспериментальный метод с количественными измерениями.

Анализ существующих подходов к реактивному рендерингу Реактивный рендеринг - автоматическое обновление DOM при изменении данных приложения [1]. По типу реактивного механизма существующие решения делятся на два класса: проприетарные, реализованные в каждом фреймворке по-своему, и стандартизируемый - основанный на предложении TC39 Signals. Первый класс представлен пятью категориями подходов, различающимися способом отслеживания изменений и обновления DOM (от виртуального дерева до fine-grained сигналов). Второй на момент работы представлен экспериментальным микро-фреймворком на базе полифилла signal-polyfill. Общая классификация приведена на рис. 1.

Рисунок 1. Классификация подходов к реактивному рендерингу веб-интерфейсов Virtual DOM (React, Preact). Разработчик декл… — см. PDF статьи.

Реактивность через Proxy (Vue 3). Изменения данных отслеживаются через стандартный Proxy API [9]. Реактивный модуль @vue/reactivity формально отделен от рендерера, но спецификации за ним нет - вне экосистемы Vue он остается специфичным для нее. Компиляторная реактивность (Svelte). Вместо runtime-отслеживания компилятор генерирует императивный код обновления DOM напрямую [3; 4]. Дистрибутив получается минимальным, но ценой жёсткой зависимости от этапа сборки - CDN-подключение и встроенные виджеты оказываются недоступны.

Fine-grained сигналы (Solid.js). Каждый DOM-узел подписан на конкретный сигнал и обновляется точечно [10]. По духу это близко к тому, что предлагает TC39 [5], однако API Solid. js собственный, а для JSX всё равно нужен ком- пилятор.

Легкие фреймворки без этапа сборки (Alpine.js). Реактивность объявляется прямо в HTML-атрибутах, подключение - одним тегом script>. По сценарию использования ближе всего к задачам настоящей работы, но движок реактивности точно так же закрыт и несовместим с другими.

Итог для всех пяти категорий одинаков: реактивность остаётся проприетарной концепцией конкретного фреймворка, что ведет к фрагментации экосистемы и невозможности переноса компонентов. Инициатива TC39 Signals [5; 6] нацелена на устранение этой проблемы - стандартизацию реактивных примитивов на уровне спецификации языка.

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

Архитектура строится на трёх принципах, каждый из которых снимает одно из ограничений, выявленных при анализе существующих решений (рис. 2).

Рисунок 2. Конструктивные принципы исследуемого фреймворка Стандартная реактивность. Вместо собственного механизма отсле… — см. PDF статьи.

Отсутствие этапа сборки. Фреймворк распространяется как единственный ESM-модуль, подключаемый через или CDN. По этому признаку он близок к Alpine.js, но реактивность здесь опирается на стандартизируемый, а не собственный закрытый механизм.

Реализованного набора примитивов хватает для полноценного TodoMVC - стандартизированного тестового приложения-списка задач, принятого в сообществе как эталон для сравнения фреймворков [12]. Исходный код и все тестовые реализации опубликованы в открытом репозитории [13]. Ключевые характеристики фреймворка в сопоставлении с аналогами приведены в таблице 1.

Таблица 1. Сравнение ключевых принципов рассматриваемых решений Решение Версия Механизм реактивности Виртуальный DOM Тре… — см. PDF статьи.

Размер дистрибутива - объем минифицированного бандла в сжатом виде (gzip, КБ). Для React, Vue 3, Solid.js и Alpine.js данные получены с bundlephobia.com [14]; для исследуемого фреймворка - измерены через сборку в Vite (ESM, production).

Производительность DOM-операций - время (мс) типовых действий с динамическим списком из 1 000 строк: создание, замена, частичное обновление, выбор и удаление. В качестве инструмента выбран js-framework-benchmark [15]. Данные для пяти фреймворков взяты из опубликованных результатов этого репозитория; замеры исследуемого фреймворка выполнены по эквивалентной методике - Chrome, пятикратное повторение, исключение первого прогона как JIT-разогрева [13].

Объем прикладного кода - содержательные строки (LOC) реализации TodoMVC [12]. Реализации React, Vue 3, Svelte и Solid.js взяты из tastejs/ todomvc [12]; для Alpine.js официальная версия отсутствует. Реализация исследуемого фреймворка - файл examples/todomvc/app.ts [13].

Таблица 4. Объём кода TodoMVC (содержательных строк, без пустых и комментариев; источники: tastejs/todomvc [12], исследу… — см. PDF статьи.

Наибольший выигрыш от исследуемого подхода достигается там, где одновременно критичны малый размер дистрибутива и работа без инструментов сборки: встроенные виджеты, статические сайты с интерактивными элементами, подключение через CDN. Для крупных SPA с серверным рендерингом и развитой инструментальной экосистемой зрелые решения вроде React и Vue остаются более обоснованным выбором. Вместе с тем использованный бенчмарк js-frameworkbenchmark измеряет операции на одном плоском списке строк. Нам не удалось охватить такие характерные для реальных приложений сценарии, как многоуровневая вложенность компонентов и обновления, приходящие асинхронно (по таймерам, сетевым запросам, пользовательским событиям) - это направление для дальнейшего исследования. Кроме того, TC39 Signals на момент работы находился на стадии Stage 1 [5], и вместо нативной реализации использовался полифилл. Заключение Проведенное исследование подтверждает:

стандартизированных реактивных примитивов TC39 Signals достаточно для построения конкурентоспособного фреймворка рендеринга в классе задач, где критичны минимальный размер дистрибутива и отсутствие этапа сборки.

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

Экспериментальное сравнение по трём метрикам дало следующие результаты. По размеру исследуемый фреймворк (4,04 КБ gzip) меньше React в 10,9 раза и Alpine.js - в 3,7 раза. По производительности точечных операций он втрое быстрее Solid.js и в 15 раз быстрее React. По объёму кода - 179 строк в одном файле против 199 строк в девяти у React - при схожем функциональном охвате и без инструментов сборки.

Настоящая работа является первой эмпирической оценкой применимости полифилла TC39 Signals как основы фреймворка рендеринга.

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