Самый популярный на сегодняшний день преемник устраняет пробел, созданный его предшественником.
Чтобы разобраться в изменчивой структуре фреймворков, заглянем в эпоху JQuery.
В то время кросс-браузерная поддержки для любого веб-приложения была кошмаром для разработчика. JQuery (и связанные с ней библиотеки) была способом веб-разработки. Однако у нее были свои ограничения. Размер кода раздувался от множества полифилов для поддержки различных браузеров, и большую часть управления жизненным циклом приходилось выполнять отдельно, что добавляло еще больше кода.
Любой новый фреймворк, решающий некоторые проблемы, также создает новый спрос.
Со временем библиотеки эволюционировали в фреймворки и стали основой веб-приложений. В это время произошел рост разработки на основе модулей (AMDs/requireJS/Dojo и т. д.).
Предприятия быстро признали эти шаблоны и многие из этих библиотек. Вскоре в модульной экосистеме JavaScript появилось несколько несовместимых стандартов. Даже сообщество HTML обратило на это внимание и поделилось первоначальным проектом веб-компонентов.
Спецификация веб-компонента позволила расширять существующие элементы HTML, что привело к возникновению модели расширения HTML.
Несмотря на то, что эта модель не была принята браузерами нативно, она стала причиной возникновения новой эры основанных на компонентах фреймворков JS, включая AngularJS (от Google) и React (от Facebook). Они создали модель управления жизненным циклом компонентов.
Angular 1.x захватил сеть и превратился в новый стандарт веб-разработки с невероятным манипулированием HTML DOM и инновационным механизмом обнаружения изменений (Watchers).
Однако с увеличением размера приложения появилось множество проблем, в том числе падение частоты кадров при обнаружении изменений. Кроме того, при увеличении количества компонентов или наблюдателей снижалась производительность и эффективность.
ReactJS выпустил в свет улучшенный механизм обнаружения изменений и обновлений под названием Virtual-DOM, который превзошел технологии Scope and Watch от Angular.
Появившийся в скором времени Angular2.x попытался решить проблемы, созданные Angular 1, однако было уже слишком поздно, поскольку React превзошел имеющиеся на тот момент варианты.
Помимо этого, на рынке есть еще несколько игроков, таких как VueJS, которые восполняют пробелы Angular и React.
Также не стоит забывать о том, что все эти фреймворки продолжают развиваться. Каждая новая версия старается превзойти предыдущий релиз. Тем не менее в большинстве случаев они придерживаются обратной совместимости, сохраняя схожесть архитектуры ядра.
Можно ли определить шаблон?
Разработчики начинают поиск новых возможностей по следующим причинам:
- В существующей платформе есть видимые недостатки, которые не могут быть исправлены в ближайшее время или без внесения изменений (без обратной совместимости).
- Существуют альтернативные варианты, которые решают вышеуказанную проблему.
Пришло ли время отказаться от виртуального DOM (ReactJS)?
Чтобы дать ответ на этот вопрос, нужно:
- Составить список недостатков, которые нельзя исправить без внесения изменений.
- Узнать, есть ли доступные на сегодняшний день альтернативы.
Недостатки
- Все эти фреймворки в большей степени зависят от способности браузера обрабатывать их алгоритмы, такие как обнаружения изменений/наблюдатели/манипуляции с виртуальным DOM и т.д. Эффективность алгоритма сравнения не имеет значения, поскольку он всегда будет поглощать ресурсы ПО клиента. Несмотря на попытки использовать такие концепции, как веб-воркеры и Web Assembly для ускорения вычислительной мощности в браузере, основные проблемы остаются прежними.
- Приложения должны содержать все библиотеки и зависимости независимо от их размера. Средний размер современных веб-страниц превысил 2 МБ, которые в большинстве случаев содержат большое количество шаблонного кода.
Доступные альтернативы
Можно ли использовать преимущества этих фреймворков, избегая раздувания пакетов? Да!
Эра исчезающих фреймворков.
Svelte / Stencil / элементы Angular / Полимеры / Веб-компоненты — одни из примеров этой новой тенденции.
Svelte выделяется тем, что не является клиентским фреймворком, а представляет собой compile-time фреймворк. Вместо того, чтобы полагаться на обработку браузером, он выполняет большую часть работы во время компиляции и содержит только отображенные HTML/CSS/JS. Скомпилированный пакет не содержит код библиотеки и не зависит от него.
Заключение
Общая проблема большинства существующих экосистем фреймворков — перекладывание большей части шаблонного кода на клиента и сильная зависимость от ресурсов браузера для управления состояниями, маршрутизацией и т.д. Решение этих проблем в последующих релизах фреймворков — непростая задача, требующая внесения значительных изменений. В то же время, есть доступные альтернативы, не перекладывающие работу на браузеры.
Исчезающие фреймворки действительно стоят вложений и заслуживают внимания.
Читайте также:
- Первые шаги в анимации React Native
- Как предотвратить состояние гонки с помощью React Context API
- Компоненты высшего порядка в React
Перевод статьи Shashank Sharma: Is it time to move on from Virtual DOM (React)?
