Аудио версия на русском (яндекс.музыка)
Разберём что не так с фреймворками как подходом и каким может быть следующий этап развития фронтенд архитектуры.
Я разрабатываю веб приложения более 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. Такой бандл не содержит кода самого фреймворка и не зависит от него.
Так и какова закономерность? Прогресс — вот типичная закономерность. Общая проблема существует у большинства современных фреймворков, которые выплёвывают на клиент бездну внутренних методов и полагаются на браузерные ресурсы в управлении стейтом, роутинге, и подобных вещах. Решить эти проблемы в следующих релизах значит поломать обратную совместимость. И в то же время существуют альтернативы с возможностями, к которым привыкло сообщество разработчиков которые обращают внимание на то чтобы не раздувать работу браузеров.
Разберём что не так с фреймворками как подходом и каким может быть следующий этап развития фронтенд архитектуры.
Я разрабатываю веб приложения более 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 фреймворках и принять обоснованное решение в развитии частного или корпоративного проекта.
Griboks
Я вижу развитие в следующих направлениях:
1. Убрать помойку jsx тегов из js, а js из css. У каждого языка как инструмента есть своя цель и область применения. Скорее всего, все подобные извращения перейдут в нативный js, например json-dom.
2. Избавиться от npm с его горой мусора.
3. Выкинуть все эти трекеры, метрики и другие уродства современного веба. Говорите, пересекли черту в 2 мб? Ну так вот 1 мб — это реклама, шпионы, майнеры и трекеры. Ещё 0,99 мб — это бесполезный библиотечный полифил и никогда неиспользуемые методы. Ну и остаётся чистый код на 1000-10 000 строчек, который можно сжать до 100 кб максимум.
babylon
Вижу большую отрицательную корму сразу подписываюсь. Проблема использования js в css в том, что css никак архитектурно не развивается. Хотя мог бы поддерживать иерархию display objects, но нет! Не надо нам архитектурного подхода. Нам надо колбасить БЭМ. Был бы css-display дом и json-dom не понадобился бы. А пока можно сколько угодно смотреть в любых направлениях. Увидите многолетний тупик. За которым стоит кто-то конкретный.
adictive_max
Griboks
Это же статья про следующее поколение веба. Npm ужасен, и нельзя игнорировать эту проблему. Вполне вероятно, разработают другой менеджер пакетов, который не будет таким плохим. И это я ещё молчу про nodejs.
Ashot
Так а что в нём ужасного-то?
Akuma
Молоток ужасен потому что я бью им по пальцам.
Ashot
Чёрт, случайно поставил вам минус вместо полюса, а отменить нельзя. Дико извиняюсь.
Akuma
Ну хоть не в карму. А то я запарился уже писать раз в 5 минут, жутко бесит :)
Griboks
Давайте рассмотрим простой пример. Я написал сайт, хочу банально сжать js. Гуглю «npm js minify», открываю первую ссылку на пакет minify-js.
Окей, давайте разберём этот пакет:
1. files отсутствует, значит весь репозиторий будет установлен
2. .npmignore отсутствует
3. .gitignore пустой
4. 3 дополнительные зависимости (видимо, очень необходимо для сжатия текста!!!)
Теперь посмотрим размер пакета: 41,3 КБ,
и размер самого скрипта сжатия: 4,64 КБ.
Вопрос… Почему размер пакета в 10 раз больше? Почему вместо одного файла я получил 40 файлов? Почему это повторяется для каждого проекта, для каждой зависимости?
justboris
Есть же нормальный минификатор – https://www.npmjs.com/package/terser
То есть все ваши претензии к npm заключаются в плохом seo, что гугл показывает не те пакеты в топе?
Ashot
Отсюда опять возникает вопрос: а при чём тут npm и что конкретно ужасно в npm(именно в пакетном менеджере, а не в кривых пакетах в нем опубликованных)?
В общем Akuma прав — вы бьете себе по пальцам молотком и вините в этом молоток.
Griboks
Вы не поняли суть примера. NPM приносит в систему кучу мусора, занимает неоправданно много места, размножает огромное количество файлов и папок и в целом даёт огромный оверхед аналогично тому, как электрон даёт огромный оверхед для декстопных приложений.
Опять же, мы говорим про разработку, а не деплой. И если молоток — это npm, а саморез — это браузер, то да, нужно постараться, чтобы закрутить его молотком.
Но давайте всё-таки говорить про разработку. Мы пишем код для браузера в чужом окружении. Так почему это окружение должно быть нодовское с его npm, когда есть множество других, например питон? Питон не требует 100500 пакетов и 100 мб места на диске, чтобы собрать и сжать скрипты в один большой бандл.
staticlab
Так кто же вам самому мешает пользоваться питоновскими утилитами? Просто если фронтендеры по определению знают JS, то логично, что им будет удобнее и тулзы писать на нём же. Опять же, вот если взять python: я гуглю
pip js minify, мне вываливается css-html-js-minify. Архив с исходниками весит 550 КБ, что более, чем в 10 раз превышает размер minify-js. В issues жалуются, что он сжимает неправильно. При этом я сильно сомневаюсь, что он сожмёт так же эффективно, как terser. Ну а просто собрать все файлы в один может и cat.Griboks
Я пользуюсь всеми доступными возможностями и инструментами в зависимости от ситуации. Спросили про проблемы npm — я ответил.
После установки весит 44,5 КБ из которых 23,4 КБ занимает сам скрипт, который ещё и не сжат.
staticlab
Так если даже после установки пакет весит практически столько же, сколько и minify-js, то в чём претензии к последнему?
Griboks
Вы разучились читать? Оверхед от питон пакета составляет 2 раза, а от npm — 10 раз. Вы что, не видите разницу? Попробуйте ещё раз прочитать мои сообщения, особенно ту часть, где я описываю свои претензии к npm.
VolCh
А как ваши претензии к конкретному пакету относятся к менеджеру пакетов? Это что требования npm оставлять пустым .gitignore и не делать files?
Griboks
Никак, вы ошиблись. Но мои требования к менеджеру пакетов относятся и ко всем его пакетам. Эти требования вы можете прочитать выше, чтобы не задавать больше таких глупых вопросов.
Xuxicheta
Если честно, к pip возникает гораздо больше вопросов, чем к npm.
Ashot
Так а что вы подразумеваете под мусором? Пакеты опубликованные в npm? Пакеты, которые вы ставите?
Я так и не понял ужачности npm из ваших объяснений. Мне кажется эти ваши "претензии" можно приплести к любому пакетному менеджеру, хоть к тому же composer.
justboris
Да что уж там, давайте закроем интернет, потому что там можно найти плохие сайты /sarcasm
nin-jin
MAM же.
av_in
Да. NPM с вахтёрами. Потому что качество того что туда попадает и что там лежит, не контролируется никак. Библиотеки с однострочным методом внутри, мусорные файлы в пакетах, мёртвый код, неподдерживаемые проекты и просто библиотеки самого низкого качества.
Всем кто не согласен, предлагаю хорошенько покопаться в node_modules своего проекта. Но лучше не стоит так себя расстраивать. Потому что всё это напоминает горящий бордель, в котором у половины проституток вич, а у второй — туберкулёз.
justboris
А кто будет назначать этих "вахтёров"? И что вы будете делать, если их мнение по поводу некоторых пакетов отличается от вашего?
av_in
Предлагаю вспомнить как мейнтейнятся репозитории в этих ваших линупсах. И ещё: когда в npm вообще не было никаких ограничений, был left-pad. И мы все хорошо помним к чему это привело
justboris
За все репозитории не скажу, но в ubuntu закрутили гайки настольно сильно, что большинства нужных пакетов там нет, и их приходится ставить из PPA. Даже собственно Nodejs рекомендует ставить их пакет из стороннего PPA, потому что в основном репозитории пакет не обновлялся уже год.
Там ещё есть история где мейнтейнеры debian репозитория сломали Node, потому что обладали своим особым взглядом на то, как именно она должна собираться.
Кто выигрывает в этой ситуации? Явно не пользователи, потому что единого репозитория пакетов они не получили.
Static555
Если открыть старый проект на php, который делал начинающий кодер 10 лет назад, там будет такая же каша из верстки и кода, как в jsx. Удивительно, как можно было наступить на те же грабли сегодня
justboris
Экспресс-тест, способен ли разработчик к критическому мышлению, или он просто повторяет что ему внушили – это спросить что он думает про JSX.
Static555
Экспресс-тест, способен ли разработчик к критическому мышлению, или он просто повторяет что ему внушили – это спросить, есть ли к него бэкграунд в других областях и есть ли с чем сравнивать
justboris
Если это был вопрос ко мне, то да, бэкграунд есть и сравнивать есть с чем. Конкретно про JSX я уже изложил свои рассуждения здесь: https://habr.com/en/post/311226/
VolCh
А если разработчик задолго до Фейсбука пытался сделать что-то подобное?
MaM
Дак никто в здравом уме и не смешивает верстку с бизнес логикой. Мещают как правило логику представления/поведения компонента с версткой. Тоесть вот, что произойдет, если такое то свойство изменится, или что делать, если произошло вот это. А сама бизнес логика она вообше как правило в редаксе, а связь компонента с самим редасом производится по средствам партикал апллкейшена. Ну я не фронтендер, сужу настолько насколько сам понимаю. Но чисто по моему мнению, реакт это вообше лучшее для написания гуи, с позиции скорость/простота/гибкость, что есть на сегодняшний день.
Heian
Удивительно, как можно иметь 10ти летний опыт и не видеть разницы между JSX и кашей из бизнес-логики с разметкой. На минуточку, это суть разные вещи. Может, пхпшникам этого не понять, но разделение обязанностей не распространяется на компоненты, в них все — о внешнем виде. JSX нереально удобен, он лучше, чем, например, подход Vue, где ты просто оперируешь строками. JSX сродни шаблонизатору. Единственный его минус в том, что он возвращается из функций.
Static555
«разделение обязанностей не распространяется на компоненты» — такое не понять не только пхпшникам, но и любым другим программистам (я, кстати, не пхпшник)
не хочу лезть во вкусовщину о том, кому как удобнее
опыт мне говорит о том, что любой нормальный фреймворк делает все, чтобы выстрелить себе в ногу, а за одно бизнесу и коллегам, было как можно сложнее. Реакт почему-то делает это не везде. В JS в целом пока царит Дикий Запад, на устоявшихся платформах о таком вообще не спорят