Пришло Ли Время Покинуть Виртуальный Дом [React]?

JQuery и связанные с ним библиотеки были основным способом сделать все для всех за один раз.

И все же мне пришлось споткнуться и здесь.

Размер загружаемого кода раздулся из-за полифилов для разных браузеров, а контроля над выполнением разных плагинов вообще не было.

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

Это был рассвет развития модульной архитектуры.

Появились фреймворки с асинхронными модулями (AMD), requireJS, Dojo и их современники.

Предприятие оперативно отреагировало и включило появившиеся инновации в свои разработки.

Итак, вскоре уже существовало несколько несовместимых стандартов, зародившихся внутри модульной экосистемы Javascript. Даже сообщество HTML ухватилось за возможность присоединиться к веселью и выпустить проект стандарта веб-компонентов.

Браузеры не спешили поддерживать такие возможности изначально.

И тем не менее, это породило новую эру компонентных фреймворков, таких как Angular и React. Они дали нам возможность управлять жизненным циклом компонентов, а остальное вы наверняка знаете сами.

Все это было не быстро и не очень эффективно при использовании среднего или большого количества компонентов и наблюдателей.

На тот момент он превосходил Angular по производительности.

А затем Angular эволюционировал во 2 версию в попытке решить проблемы 1, однако произошло это несколько позже, чем должно было случиться, так как React к тому времени уже захватил железный трон.

Помимо этих двух персонажей, на этой сцене есть и другие.

Например, View, который лучше себя проявляет в моменты, когда Angular и React ему уступают. История продолжается, и эти рамки развивались.

Они выпускают новые версии, пытаясь совершенствоваться с каждым выпуском.

При этом сохраняется обратная совместимость, поэтому архитектура не меняется.

Итак, все те фреймворки, о которых мы говорили ранее, в своей работе в основном полагаются на браузер.

Как пример: отслеживание изменений на странице и в объектах, наблюдателях, виртуальном доме.

Независимо от того, насколько эффективен алгоритм сравнения, он всегда будет съедать аппаратные ресурсы клиента.

Хотя были попытки использовать обходные пути, такие как веб-воркеры и компиляция байт-кода, для ускорения выполнения, однако основные проблемы остаются теми же.

Приложение должно быть доставлено пользователям с включенными библиотеками и зависимостями, независимо от того, насколько оно маленькое или большое.

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

Svelte, в частности, изначально привлек мое внимание, потому что это скомпилированный фреймворк.

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

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

Решение этих проблем в будущих выпусках означает нарушение обратной совместимости.

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