Аудио версия на русском (яндекс.музыка) / iTunes
Разберём что не так с фреймворками как подходом и каким может быть следующий этап развития фронтенд архитектуры.
Я разрабатываю веб приложения более 10 лет, и за это время наблюдал рассвет и падение множества Javascript библиотек и фреймворков. Одни сменяют другие, разные подходы к архитектуре перемежаются друг другом, и в этом адском бульоне изменения неотвратимы.
Как разработчика меня занимает существует ли фундаментальный принцип этой эволюции, и что важнее, можем ли мы предсказать следующий шаг на этом пути?
Чтобы понять почему это происходит, давайте отойдём на шаг назад в эпоху рассвета jQuery.
Были времена когда кросс-браузерность стоила разработчикам мучений и крови. JQuery и связанные с ней библиотеки были основным способом сделать всё и для всех за один подход. И тем не менее, спотыкаться приходилось и здесь. Размер загружаемого кода распухал от полифилов для разных браузеров, а контроль над исполнением разных плагинов отсутствовал вовсе. Вишенкой же на торте было отсутствие архитектуры этих плагинов, которые хотели бы взаимодействовать между собой, однако, непонятно было как этого достичь чтобы они не вмешивались в работу друг друга.
В некоторый момент истории библиотеки начали развиваться в фреймворки и стали основой целым веб-приложениям. То было время рассвета разработки с модульной архитектурой. Появились фреймворки с асинхронными модулями (AMD), requireJS, Dojo и их современники.
Энтерпрайз среагировал быстро и включил в свои разработки появившиеся новшества. Так, скоро было уже несколько несовместимых между собой стандартов зародившихся внутри модульной Javascript экосистемы. Даже HTML сообщество, и те не упустили шанс присоединиться к общему веселью и выпустить черновик стандарта веб компонентов.
Эта спецификация, веб компонентов, включала возможность расширения существующих html элементов, что дало толчок модели расширения HTML, а использование кастомных html элементов начало набирать обороты.
Браузеры же не спешили поддерживать такие возможности нативно. И тем не менее, это породило новую эру компонентных фреймворков как то Angular и React. Они подарили нам возможность управления жизненным циклом компонентов, а дальше вы и сами, наверное, знаете.
Angular 1ой версии взорвал интернет и стал новым стандартом веб разработки с его магической возможностью динамического изменения HTML при помощи Вотчеров.
С увеличением размера приложения появлялось много проблем, среди которых падение скорости обновления и отрисовки из-за отслеживания изменений на странице и в состоянии компонентов. Всё это было не быстро, и не очень-то эффективно при использовании среднего или большого числа компонентов и вотчеров.
Реакт подоспел с улучшенным механизмом отслеживания изменений и обновления страницы который разработчики назвали виртуальной моделью документа. Он превосходил Angular в производительности на тот момент.
И тогда Angular эволюционировал в версию 2 в попытке решить проблемы 1ой, однако, это случилось чуть позже чем тому следовало случиться так как Реакт к тому моменту уже захватил железный трон.
Помимо этих двух персонажей на этой сцене присутствуют также и другие. Например, Вью который показывает себя лучше в моментах где Angular и Реакт ему уступают.
История продолжается, и у этих фреймворков есть развитие. Они поставляют новые версии в попытке улучшиться с каждым релизом. При этом, сохраняя обратную совместимость, поэтому архитектура не меняется.
Разработчики ищут новые подходы в двух случая:
Чтобы ответить на этот вопрос нам нужно две вещи:
И так, все те фреймворки что мы затронули ранее в основном полагаются на браузер в своей работе. Как пример: отслеживание изменений на странице и в объектах, вотчеры, виртуальный дом. Независимо от того, насколько эффективный алгоритм сравнения используется, он всегда будет съедать аппаратные ресурсы клиента. Хотя и были попытки использовать обходные приёмы как веб воркеры и компиляцию в байткод чтобы ускорить выполнение, однако, основные проблемы остаются теми же.
Приложение необходимо доставлять пользователям с включёнными библиотеками и зависимостями и не важно насколько маленькое или большое это приложение. Средний размер современных веб-страниц уже пересёк черту в 2 мегабайта которые в большинстве случае содержат неиспользуемые функции и методы.
Можем ли мы продолжить наслаждаться этими фреймворками, избегая перегрузку кода в сборках и бандлах? Получить идеальный девелоперский и user experience? Ну… да!
Svelte / Stencil / Angular elements / Polymers / Web components примеры тренда который набирает обороты.
Svelte, в частности, привлёк моё внимание изначально тем что это компилируемый фреймворк. Вместо того чтобы во всём полагаться на браузер, Svelte делает всю работу во время компиляции, а на клиент отправляется лишь готовый HTML, CSS и JavaScript. Такой бандл не содержит кода самого фреймворка и не зависит от него.
Так и какова закономерность? Прогресс — вот типичная закономерность. Общая проблема существует у большинства современных фреймворков, которые выплёвывают на клиент бездну внутренних методов и полагаются на браузерные ресурсы в управлении стейтом, роутинге, и подобных вещах. Решить эти проблемы в следующих релизах значит поломать обратную совместимость. И в то же время существуют альтернативы с возможностями, к которым привыкло сообщество разработчиков которые обращают внимание на то чтобы не раздувать работу браузеров.
Разберём что не так с фреймворками как подходом и каким может быть следующий этап развития фронтенд архитектуры.
Disclaimer:
Это вольный перевод статьи. Стиль повествования может не совпадать с таковым автора. Никакие идеи, домыслы, факты или суждения не были убраны или добавлены.
Я разрабатываю веб приложения более 10 лет, и за это время наблюдал рассвет и падение множества Javascript библиотек и фреймворков. Одни сменяют другие, разные подходы к архитектуре перемежаются друг другом, и в этом адском бульоне изменения неотвратимы.
Как разработчика меня занимает существует ли фундаментальный принцип этой эволюции, и что важнее, можем ли мы предсказать следующий шаг на этом пути?
Сегодня среди фреймворков наиболее популярные решают проблемы созданные своими предшественниками.
Чтобы понять почему это происходит, давайте отойдём на шаг назад в эпоху рассвета jQuery.
jQuery
Были времена когда кросс-браузерность стоила разработчикам мучений и крови. JQuery и связанные с ней библиотеки были основным способом сделать всё и для всех за один подход. И тем не менее, спотыкаться приходилось и здесь. Размер загружаемого кода распухал от полифилов для разных браузеров, а контроль над исполнением разных плагинов отсутствовал вовсе. Вишенкой же на торте было отсутствие архитектуры этих плагинов, которые хотели бы взаимодействовать между собой, однако, непонятно было как этого достичь чтобы они не вмешивались в работу друг друга.
Любой новый фреймворк, который решает проблемы также создаёт новый спрос на улучшение.
requireJS
В некоторый момент истории библиотеки начали развиваться в фреймворки и стали основой целым веб-приложениям. То было время рассвета разработки с модульной архитектурой. Появились фреймворки с асинхронными модулями (AMD), requireJS, Dojo и их современники.
Энтерпрайз среагировал быстро и включил в свои разработки появившиеся новшества. Так, скоро было уже несколько несовместимых между собой стандартов зародившихся внутри модульной Javascript экосистемы. Даже HTML сообщество, и те не упустили шанс присоединиться к общему веселью и выпустить черновик стандарта веб компонентов.
Веб компоненты
Эта спецификация, веб компонентов, включала возможность расширения существующих html элементов, что дало толчок модели расширения HTML, а использование кастомных html элементов начало набирать обороты.
Браузеры же не спешили поддерживать такие возможности нативно. И тем не менее, это породило новую эру компонентных фреймворков как то Angular и React. Они подарили нам возможность управления жизненным циклом компонентов, а дальше вы и сами, наверное, знаете.
Angular 1.x
Angular 1ой версии взорвал интернет и стал новым стандартом веб разработки с его магической возможностью динамического изменения HTML при помощи Вотчеров.
С увеличением размера приложения появлялось много проблем, среди которых падение скорости обновления и отрисовки из-за отслеживания изменений на странице и в состоянии компонентов. Всё это было не быстро, и не очень-то эффективно при использовании среднего или большого числа компонентов и вотчеров.
ReactJS
Реакт подоспел с улучшенным механизмом отслеживания изменений и обновления страницы который разработчики назвали виртуальной моделью документа. Он превосходил Angular в производительности на тот момент.
И тогда Angular эволюционировал в версию 2 в попытке решить проблемы 1ой, однако, это случилось чуть позже чем тому следовало случиться так как Реакт к тому моменту уже захватил железный трон.
Помимо этих двух персонажей на этой сцене присутствуют также и другие. Например, Вью который показывает себя лучше в моментах где Angular и Реакт ему уступают.
История продолжается, и у этих фреймворков есть развитие. Они поставляют новые версии в попытке улучшиться с каждым релизом. При этом, сохраняя обратную совместимость, поэтому архитектура не меняется.
Улавливаете закономерность?
Разработчики ищут новые подходы в двух случая:
- Когда есть видимые недостатки в существующей архитектуре которые невозможно исправить в скором времени или без нарушения обратной совместимости
- Или в случае наличия альтернатив которые могут решить эти недостатки
Настало ли время оставить виртуальный дом Реакта в прошлом и двигаться дальше?
Чтобы ответить на этот вопрос нам нужно две вещи:
- Список недостатков которые невозможно исправить без нарушения обратной совместимости
- И есть ли альтернативные подходы к этому на сегодняшний день?
Недостатки
Прежде всего, стоит заметить что Реакт — прекрасная экосистема с которой приятно работать. Я использовал Реакт некоторое время и он помогал мне разрабатывать приложения просто, эффективно и быстро.Впрочем, это не значит что он совершенен.
И так, все те фреймворки что мы затронули ранее в основном полагаются на браузер в своей работе. Как пример: отслеживание изменений на странице и в объектах, вотчеры, виртуальный дом. Независимо от того, насколько эффективный алгоритм сравнения используется, он всегда будет съедать аппаратные ресурсы клиента. Хотя и были попытки использовать обходные приёмы как веб воркеры и компиляцию в байткод чтобы ускорить выполнение, однако, основные проблемы остаются теми же.
Приложение необходимо доставлять пользователям с включёнными библиотеками и зависимостями и не важно насколько маленькое или большое это приложение. Средний размер современных веб-страниц уже пересёк черту в 2 мегабайта которые в большинстве случае содержат неиспользуемые функции и методы.
Альтернативы сегодняшнего дня
Можем ли мы продолжить наслаждаться этими фреймворками, избегая перегрузку кода в сборках и бандлах? Получить идеальный девелоперский и user experience? Ну… да!
Svelte / Stencil / Angular elements / Polymers / Web components примеры тренда который набирает обороты.
Svelte, в частности, привлёк моё внимание изначально тем что это компилируемый фреймворк. Вместо того чтобы во всём полагаться на браузер, Svelte делает всю работу во время компиляции, а на клиент отправляется лишь готовый HTML, CSS и JavaScript. Такой бандл не содержит кода самого фреймворка и не зависит от него.
И в заключение
Так и какова закономерность? Прогресс — вот типичная закономерность. Общая проблема существует у большинства современных фреймворков, которые выплёвывают на клиент бездну внутренних методов и полагаются на браузерные ресурсы в управлении стейтом, роутинге, и подобных вещах. Решить эти проблемы в следующих релизах значит поломать обратную совместимость. И в то же время существуют альтернативы с возможностями, к которым привыкло сообщество разработчиков которые обращают внимание на то чтобы не раздувать работу браузеров.
Исчезающие фреймворки действительно стоят инвестиций и заслуживают шанса проявить себя.Я надеюсь, что этот пост поможет понять закономерность постоянных изменений в JS фреймворках и принять обоснованное решение в развитии частного или корпоративного проекта.
