Не пора ли перейти от Virtual DOM (React)?
Понимание адского паттерна Фреймворка и прогнозирование следующего сдвига парадигмы.
Я занимаюсь разработкой веб-приложений более десяти лет и стал свидетелем взлета и падения многих библиотек и фреймворков JavaScript. В Framework’s Hell изменения неизбежны. Как разработчик я задавался вопросом, существует ли закономерность и, что более важно, можем ли мы предсказать следующий сдвиг?
Самый популярный преемник сегодня ликвидирует разрыв, созданный его предшественником.
Чтобы понять этот изменчивый паттерн фреймворков, давайте вернемся немного назад в эпоху JQuery.
Это было время, когда поддержка кроссбраузерности любого веб-приложения была кошмаром для разработчика. JQuery (и связанные с ним библиотеки) был де-факто способом веб-разработки. Однако у него есть свои ограничения. Размер кода увеличился с большим количеством полифилов для поддержки различных браузеров, и большая часть управления жизненным циклом должна была выполняться отдельно, что добавляло больше следов кода. Более того, большое беспокойство вызывало то, как разные плагины jQuery могут сосуществовать вместе и взаимодействовать друг с другом, не мешая друг другу.
Любой новый фреймворк решает некоторые проблемы, а также создает новый спрос.
В конце концов, библиотеки начали превращаться в фреймворки и дали скелет целым веб-приложениям. Это было время, когда был рост модульной разработки (AMD / requireJS / Dojo и т. Д.).
Enterprise быстро адаптировала эти шаблоны. Многие из этих библиотек были быстро освоены предприятиями. И вскоре в модульной экосистеме JavaScript появилось несколько несовместимых стандартов. Даже сообщество HTML приняло это к сведению и поделилось первоначальным наброском веб-компонентов.
Спецификация веб-компонентов позволяет расширять существующие элементы HTML. Это привело к появлению модели расширения HTML (пользовательские элементы HTML ‹my-elements /›).
Тем не менее, он был далек от того, чтобы быть принятым браузерами изначально, но это вдохновило новую эру компонентно-ориентированных JS-фреймворков, включая AngularJS (от Google) и React (от Facebook). Они придумали модель управления жизненным циклом компонентов, а остальное уже история.
Angular 1.x захватил Интернет как шторм и стал новым стандартом веб-разработки, волшебным образом манипулируя HTML DOM с помощью инновационного механизма обнаружения изменений (Watchers).
Однако по мере увеличения размера приложения возникло множество проблем, в том числе падение частоты кадров при обнаружении изменений. Это было не очень производительно и эффективно, когда количество компонентов или наблюдателей увеличивалось.
ReactJS предлагает улучшенный механизм обнаружения изменений и обновления под названием Virtual-DOM, который превосходит методы Angular Scope and Watch.
Вскоре появился Angular2.x, пытающийся исправить беспорядок, созданный Angular 1, но это было немного поздно, поскольку React обогнал defacto, брошенный к тому времени.
Кроме того, на рынке есть еще несколько игроков, таких как VueJS, которые лучше в некоторых аспектах, чем Angular или React.
Также помните, что все эти фреймворки тоже развиваются. Они выпускают новые версии, пытаясь улучшить в каждом последующем выпуске. Однако в большинстве случаев они придерживаются обратной совместимости, сохраняя схожую архитектуру ядра.
Вы можете заметить здесь узор?
Разработчики ищут новые возможности, когда
- В существующей структуре есть видимые недостатки, которые нельзя исправить в ближайшее время или без критических изменений (отсутствие обратной совместимости).
- Доступны альтернативные варианты, которые решают указанную выше проблему.
Не пора ли перейти от Virtual DOM (ReactJS)?
Чтобы ответить на этот вопрос, нам нужны две вещи
- Список недоработок, которые нельзя исправить без критических изменений
- Есть ли у нас альтернативы сегодня?
Недостатки 👎🏻
Отказ от ответственности. ReactJS - отличная экосистема для работы. Я использую React с некоторого времени, и это помогло мне эффективно и быстро доставлять веб-приложения. Однако это не значит, что он безупречный.
- Все эти структуры, которые обсуждались до сих пор, во многом зависят от способности браузера обрабатывать их алгоритм. Пример обнаружения изменений / наблюдателей / манипуляций с виртуальной DOM и т. Д. Независимо от того, насколько эффективен алгоритм сравнения, он всегда будет поглощать аппаратные ресурсы клиента. Хотя было несколько попыток использовать различные концепции, такие как Web Workers, Web Assembly, для увеличения вычислительной мощности в браузере, все же основные проблемы остаются теми же.
- Приложения должны поставляться с библиотеками и зависимостями, независимо от того, насколько маленьким или большим является само приложение. Средний размер современных веб-страниц превышает 2 МБ, и в большинстве случаев они содержат множество шаблонов.
Альтернативы сегодня
Можем ли мы и дальше пользоваться преимуществами этих фреймворков, избегая раздувания пакетов? Отличный разработчик и пользовательский опыт? Что ж, да!
Эпоха исчезающих рамок
Svelte / Stencil / Angular elements / Polymers / Web-компоненты являются примерами этой новой тенденции.
В частности, изначально мое внимание привлек Svelte, поскольку это не клиентская среда; вместо этого это фреймворк времени компиляции. Вместо того, чтобы сильно полагаться на браузер для обработки, он переносит объемную работу во время компиляции и, наконец, отправляет только визуализированные HTML / CSS / JS. Скомпилированный пакет не содержит и не зависит от кода библиотеки.
Заключение
Так что же это за образец? Прогресс - это типичный образец. Общая проблема существует с большей частью существующей экосистемы фреймворка, которая передает клиенту много шаблонного кода и сильно полагается на ресурсы браузера для управления состоянием, маршрутизации и т. Д. Эти проблемы трудно решить в последующем выпуске фреймворки с критическими изменениями. И в то же время доступны альтернативы, которые продолжают давать преимущества, к которым привыкло текущее сообщество разработчиков, не перегружая браузеры.
Исчезающие фреймворки действительно стоят вложений и заслуживают того, чтобы их попробовать.
Я надеюсь, что этот пост поможет понять постоянно меняющуюся структуру JS-фреймворка и поможет принять обоснованное решение при разработке частного или корпоративного проекта.
Ресурсы
Особая благодарность Питеру О'Шонесси и Ричу Харрису - переосмысление реактивности для объединения всех точек воедино.
