Библиотека Vue.js с каждым днем набирает все больше и больше популярность, хотя не все понимают почему именно Vue, и в каких именно случаях последнюю можно и нужно использовать.
Технически, Vue.js определена как ViewModel слой шаблона MVVM. Она соединяет модель и представление в двустороннее связывание данных. Текущие DOM-изменения и форматированный вывод абстрагируются в Директивах и Фильтрах.
Цель предоставить преимущества быстрых связываний данных и сложных представлений компонентов с API как простые, так и понятные. Библиотека не является полномасштабным фреймворком, она является всего лишь уровнем представления. Вы можете использовать ее как отдельно, для быстрого прототипирования приложений, или смешивать и сочетать с другими библиотеками для кастомизации пользовательского интерфейса.
На Vue.js значительно повлияли Angular, Knockout, React и Rivets. Несмотря на сходства, Vue.js может предложить ценную альтернативу этим существующим библиотекам, в поисках золотого сечения между простотой и функциональностью.
В чем разница между Vue.js и Angular.js?
Есть несколько причин использовать Vue.js вместо Angular, хотя не все они могут применяться ко всем проектам:
- Vue.js более гибкий, менее прямолинеен в решение. Это позволяет структурировать ваше приложение как вы хотите, а не вынуждает делать все это как в Angular. Vue является только слоем представления, поэтому вы можете использовать его как ненавязчивую особенность на странице приложения, вместо полномасштабного фреймворка. Это дает вам больше возможностей для сочетания Vue с другими библиотеками, но вы также несете ответственность за более архитектурные решения. Так, например, ядро Vue.js не включает маршрутизацию или ajax-функции из коробки, и, как правило, предполагает, что вы строите приложение, используя внешний модуль. Это, вероятно, наиболее важное различие.
- Vue.js гораздо проще, чем Angular, как с точки зрения API, так с точки зрения дизайна. Вы можете изучить практически все аспекты Vue.js достаточно быстро, и сразу начать писать.
- Vue.js имеет более высокую производительность, потому что не использует "dirty checking". Angular становится более медленным, когда используются множество наблюдателей, потому что каждый раз при изменениях в области видимости, всем этим наблюдателям необходимо вычисляться снова. Vue.js не страдает от этого, потому что использует прозрачную систему отслеживания наблюдателей, поэтому все изменения вызываются самостоятельно, при наличии явных связанных зависимости.
В чем разница между Vue.js и React.js?
- React и Vue.js имеют небольшое сходство в том, что оба поддерживают реактивные и компонуемые представления компонентов. Тем не менее внутренняя реализация в корне отличается. React основан на виртуальном DOM — в памяти представлено то, как DOM выглядит на самом деле. Данные в React в значительной степени являются неизменными, и DOM-изменения рассчитываются на основе определения различий. В Vue.js, напротив, данные изменяемы по умолчанию, и изменяются через события. Вместо виртуального DOM, Vue.js работает напрямую с DOM в качестве шаблона, сохраняя ссылки на существующие узлы для связывания.
- Подход с виртуальным DOM обеспечивает функциональный способ описать ваше представление в любой момент, это очень приятно. Потому что не используется шаблон наблюдателей и не перерисовывается все приложение при каждом обновление, представление по определению гарантирует быть синхронизируемым с данными, что также открывает возможности для изоморфных JavaScript-приложений.
- Но проблема при использовании React в том, что ваша логика и представление тесно переплетаются. Для некоторых разработчиков это плюс, но для дизайнеров/разработчиков гибридов, представлять шаблон наглядно гораздо проще в дизайне и CSS. JSX сливаясь с Javascript-логикой ломает ту визуальную модель, которая необходима для отображения кода в дизайне. Vue.js, в отличие, расплачивается своими легковесный директивами, но у вас всегда есть визуально представленный шаблон и инкапсулированная логика в директивах и фильтрах.
- Еще одна проблема React заключается к том, что все обновления делегированы на виртуальный DOM, это немного сложно, когда вам на самом деле требуется контролировать DOM самостоятельно(хотя теоретически можно, следует по сути работать в противовес библиотеке, когда это необходимо). Для приложений, которым нужна сложно-синхронизированная анимация по времени это может стать очень раздражающим ограничением. На этом фронте Vue.js является более гибким.
В чем разница между Vue.js и Polymer?
Polymer — это еще один проект, спонсируемый Google, который также вдохновил Vue.js. Компоненты Vue могут быть более слабосвязанными, чем кастомизированные элементы Polymer'а, но оба обеспечивают похожий стиль разработки. Самым большим отличием является то, что Polymer построен на новейших особенностях web-компонентов, а также требует нетривиальных полифилов для работы(чем снижает производительность) в браузерах, которые не поддерживают эти новейшие особенности. Vue.js, в отличие, работает без каких-либо зависимостей, вплоть до IE9.
В чем разница между Vue.js и KnockoutJS?
Во-первых, Vue обеспечивает более чистый синтаксис геттеров и сеттеров у VM свойств.
На более высоком уровне, Vue отличается от Knockout тем, что в Vue данные являются простыми, менее логически содержащими объектами(такие, что вы можете прямо использовать JSON.stringify и пробросить их после запроса), а ViewModel просто предоставляет интерфейс доступ к этим данным. Vue VM экземпляр всегда связывает исходные данные с соответствующим DOM-элементом. В Knockout, ViewModel по сути является данными, и грань между моделью и слоем ViewModel получается довольно размытой. Отсутствие разделения на части в Knockout вероятно приведет к запутанным ViewModel.
Само по себе — использование библиотеки Vue.js не сводится к панацеи. Библиотека имеет также свои узкие места и не тривиальные решения, но однозначно Vue заслуживает внимания при разработке интерактивных пользовательских интерфейсов.
На просторах интернета довольно много англоязычных обучающих материалов по данной библиотеки, но также существует и русскоязычные уроки для освоения «честного MVVM»: ausite.ru
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (30)
xelam
25.09.2015 16:58+1Много уроков и статей в нашем сообществе vk.com/vuejs + чат gitter.im/vuejs-ru/Discussion и официальный форум forum.vuejs.org
lega
25.09.2015 20:57+4Vue.js имеет более высокую производительность, потому что не использует «dirty checking». Angular становится более медленным, когда используются множество наблюдателей, потому что каждый раз при изменениях в области видимости, всем этим наблюдателям необходимо вычисляться снова. Vue.js не страдает от этого, потому что использует прозрачную систему отслеживания наблюдателей, поэтому все изменения вызываются самостоятельно, при наличии явных связанных зависимости.
Во первых, отсутствие «dirty checking» не гарантирует большую производительность (см. на тормозной knockout.js)
Во вторых, vue.js использует «dirty checking» или аналог (называйте как хотите), причем медленный (в Angular он отточен), вот перебор ватчей, а вот непосредственное изъятие значения на каждый ватч, да тут используется некоторое отслеживание зависимостей (которое не каждый раз используется), и поэтому такие штуки как вызов метода "{{fn()}}" тут работают криво, либо не работают вообще. Так же данные оборачиваются в геттеры/сеттеры что накладывает дополнительную нагрузку.
В третих, каждый фреймворк/библиотека быстрее «конкурента» в чем том своем, для каждого фреймворка можно сделать тест где он быстрее всех остальных. А производительность конечного проекта (в первую очередь) зависит от профессионализма разработчика, а не от фреймворка.
PS: Не могли бы вы добавить vue.js в местный хабра-бенчмарк, что-б увидеть на сколько он быстр.
nuit
26.09.2015 06:49>PS: Не могли бы вы добавить vue.js в местный хабра-бенчмарк, что-б увидеть на сколько он быстр.
Не местный хабра-бенчмарк, но хотяб какой-то mathieuancelin.github.io/js-repaint-perfs. На этом бэнчмарке реализации с дата-байндингом на kvo должны в теории быть быстрее всех остальных на низком кол-ве мутаций, это идеальный кэйс для Vue.
Vue: mathieuancelin.github.io/js-repaint-perfs/vue
Angular2 alpha: mathieuancelin.github.io/js-repaint-perfs/angular2/opt.htmllega
27.09.2015 14:22Добавил Angular Light (сделал пулл-реквест) для теста, по скорости он получился один из самых быстрых, если не самый быстрый, у меня он чуть быстрее чем Angular 2 (40fps против 38fps у Angular 2).
Кстати для Angular 2, fps снижается со временем, за 2 мин он упал до 29, так же потребление памяти растет если смотреть внешними утилитами, возможно в нем есть утечка.nuit
27.09.2015 14:40неплохой результат, вот для сравнения моя либа с реализацией виртуального дома kivi dbmonster.
И несмотря на кучу лишних операций при использовании виртуального дома вместо kvo, когда кол-во мутаций выставлено на 1%, подход с использованием виртуального дома может работать довольно таки быстро :)lega
27.09.2015 15:55когда кол-во мутаций выставлено на 1%, подход с использованием виртуального дома может работать довольно таки быстро :)
Так же и с «dirty-checking», потому что основная нагрузка — DOM.
Для virtual-dom даже при малых изменениях, происходит сверка всего (большого куска) DOM, можно даже назвать это «dirty-checking dom». Поэтому React проигрывает Angular'у в этом тесте.nuit
27.09.2015 16:03В kivi так же происходит дифф полного списка чилдренов, вместо точечных изменений.
React проигрывает потомучто там было сделано несколько плохих архитектурных решений, от которых сейчас довольно сложно избавиться.lega
27.09.2015 16:45В kivi так же происходит дифф полного списка чилдренов, вместо точечных изменений.
Значит этот virtual-dom тоже будет медленным в большом DOM, который генерируют «крутые» дизайнеры. Те же формы, диалоги и пр. У меня попадаются задачи где 5 ватчей на 200 DOM элементов. Данный тест — «голая» таблица (~1900 ватчей), можно сказать идеальный тест для virtual-dom.
Опять же приходим к выводу, что брать virtual-dom из-за скорости смысла нет.nuit
27.09.2015 16:59это идеальный тест для virtual-dom когда кол-во мутаций: 100%, идеальный тест для kvo когда: 1%, и плохой для dirty checking'а при любом кол-ве мутаций. И несмотря на самую худшую ситуацию для виртуального дома, когда изменения происходят только на 1% контента, каким-то образом либы, использующие kvo работают тормознее чем virtual dom.
boolive
26.09.2015 02:30Существенным недостатком для меня оказалась невозможность динамически добавить компоненты в страницу или просто поменять шаблон у компонента (получить его с сервера и скомпилировать). В приложении изначально должна быть определена иерархия компонентов, можно управлять только видимостью компонентов. Подгружать с сервера компоненты идеологически нельзя и автор не намерен это делать или принимать пул. реквесты по этой теме.
lega
26.09.2015 04:01Можете попробовать Angular Light, там есть возможность динамически добавлять директивы (компоненты), наследовать их и переименовывать, так же делать приватные наборы директив.
saggid
26.09.2015 12:28Советую Riot.js вместо всего, что было перечислено. Рендеринг на стороне сервера, очень простой механизм работы компонентов, при этом дающий делать все что может понадобиться. быстрый, маленький… использую уже почти год, очень доволен.
plashenkov
27.09.2015 11:35+1Кстати, на сайте Vue есть сравнение и с Riot: vuejs.org/guide/faq.html.
По какой-то причине не вошло в перевод. Переведу:
Riot 2.0 предоставляет схожую модель, основанную на компонентах (в Riot они называются тегами — “tag”), с минимальным и прекрасно спроектированным API. Я думаю, что Riot и Vue разделяют многие архитектурные принципы. Тем не менее, несмотря на то, что Vue является чуть более «тяжелым», чем Riot, он также предлагает некоторые существенные преимущества:
- Настоящий условный рендеринг (Riot выводит все “if” ветки и просто прячет / показывает их);
- Значительно более мощный ротер (API роутинга, предоставляемый Riot, просто крайне минимальный);
- Более зрелая поддержка инструментов (см. webpack + vue-loader);
- Система «эффектов перехода» (transition effect) (Riot не имеет таковой);
- Лучший статус поддержки (на 31 августа 2015 г. Riot имеет 25 открытых багов, в то время как у Vue их 0);
- Лучшая производительность (Riot, по факту, использует скорее прямую проверку (dirty checking), чем virtual-dom, и потому страдает от тех же проблем с производительностью, что и Angular).
От себя могу добавить, что автор Vue действительно крайне оперативно реагирует на задачи. Как-то я написал ему о встреченном баге, и он буквально тут же его исправил.saggid
27.09.2015 13:29Это не существенные преимущества. Кое-где это просто различные подходы, а кое-где автор Vue.js даже соврал, я бы сказал.
1. Верно, но оно никак не мешает разработке, это не является действительно страшной проблемой;
2. Есть же еще плагины от комньюнити, помимо основного функционала. У Riot.js есть прекрасный набор дополнительных компонентов RiotGear: http://riotgear.js.org/components/. Там вам и роутер полноценный, и автокомплитер, и контекстное меню, и селект, и табы, и так далее, и так далее. Очень много всего полезного, легко забирается в свой проект и используется по назначению.
3. По-моему, она скорее менее зрелая, чем более. Riot.js прекрасно чувствует себя вместе с Jade, Coffescript, TypeScript, [ваш редкий компилятор], Sass, поддерживает загрузку по AMD и CommonJS. Я не нашёл ничего подобного у Vue.js, кроме указанной вами поддержки Вебпака, которая есть и у Riot.js. Я лично в данный момент пишу свои компоненты на основе Riot.js + Jade + Sass, компилируя всё это на серверной стороне с помощью Node.js в обычные JS файлы и подключая их впоследствии к сайту и компилируя всё в одно целое на продакшене через Grunt.js. Vue.js так умеет?
4. Да, у Riot.js нет своей системы анимации, но он же не запрещает управлять свойствами DOM элементов самостоятельно. Поэтому вы банально можете использовать любую другую библиотеку для плавного изменения свойств ваших элементов, например запустить jQuery.animate(). И опять же, эта проблема не настолько великая, всё это легко реализуется через добавление CSS-классов к нужным объектам и анимируется тем же самым CSS, что я лично и делаю.
5. Ну это же вообще просто попытка меряния пипиндрями через какие-то статистические цифры… Разработчики Riot.js просто не отказываются от feature request'ов и обрабатывают их, вместо того, чтобы придумывать благовидные предлоги для отказа. Когда кто-то предложил реализовать рендеринг на стороне сервера с помощью Node.js, они обсудили всё это дело вместе с сообществом и реализовали через какое-то время. Как эту проблему решили авторы Vue.js, уже описано выше в комментариях к этой теме.
6. Riot.js недавно доработали до производительности, более высокой, чем React от фейсбука. В тонкостях я не шарю, но по крайней мере, глупо здесь утверждать на пустом месте, что одна библиотека более быстрая, чем другая. Я не вижу никаких проблем со скоростью у Riot.js.
И авторы Riot.js также оперативно реагируют на issues в своём репозитории. Я также задавал им вопросы о том, как более правильно компилировать их компоненты, написанные на основе Jade шаблонизатора, и мы вместе обсуждали этот вопрос и пришли к наиболее корректному решению. Вот эта ветка обсуждения: https://github.com/riot/riot/issues/1194nuit
27.09.2015 15:22+1А ещё авторы riot.js отлично умеют врать «Absolutely the smallest possible amount of DOM updates and reflows» :)
saggid
28.09.2015 16:22Быть может, они и солгали где-то в другом месте, но данная фраза является чистой правдой: Riot.js обновляетв своих компонентах только то, что нуждается в обновлении, не затрагивая уже созданный ранее DOM. Более того, если вы будете рендерить ваши компоненты на сервере и на клиенте с одинаковыми параметрами, то при монтирования тега вообще ничего не будет обновлено.
Riot.js очень разумен в этом плане, и благодаря этому легко позволяет совмещать себя с любыми другими библиотеками, будь то jQuery или ещё что-либо, что будет изменять свойства ваших DOM элементов.nuit
28.09.2015 18:55Я отлично знаю как работает riot.js, например советую взглянуть на реализацию each github.com/riot/riot/blob/master/lib/browser/tag/each.js
p.s. никому бы не советовал использовать riot.js в более менее серьёзных проектахsaggid
29.09.2015 17:33Я рад за вас, что вы отлично его знаете. Ну а я уже четыре проекта вместе с Riot.js написал, и я бы не сказал, что задачи, решаемые в ходе работы над этими проектами, были простыми, а конечный результат работы сайтов оказывался плохим.
Если вы под «более менее серьёзными проектами» подразумеваете какие-то сверхдинамичные веб-приложения, или еще что-то действительно очень требовательное к процессору — то конечно, возможно и есть смысл поискать что-то другое. Однако, на данный момент, во всех задачах разработки веб-интерфейсов, которыми я занимался, Riot.js прекрасно себя показал и убедил меня в адекватности его авторов более чем хорошо.
plashenkov
27.09.2015 15:42кроме указанной вами поддержки Вебпака
Не мной, а автором Vue. Я всего лишь перевел (так сказать, для полноты картины).
Я-то вообще «ровен» к разным библиотекам и ни в коем случае на агитирую за Vue и против Riot.
Спасибо за ваше дополнение. Лично я обязательно взгляну на Riot поближе.
vird
30.09.2015 01:12riotjs.com/api/#reserved-words
Пока бросилось вот это в глаза. В том же Angular тебя защищают при помощи $$ префикса. Дополнительный способ выстрелить себе в ногу.saggid
30.09.2015 18:09Вы просто не знаете о том, что эти девять слов, перечисленных в этом разделе, вы в любом случае запомните наизусть уже через пару дней работы с данной библиотекой :) Эти слова — как переменные и методы родительского класса, от которого наследуются все ваши Riot-тэги. Любой ваш компонент будет использовать эти методы и переменные в своей работе.
В общем, это совершенно не относится к ситуациям с прострелами ног. Да и вообще, там всё настолько просто и элегантно сделано, что, в общем-то, чтобы запутаться там и реально прострелить себе ногу — надо очень постараться)vird
30.09.2015 19:40Я-то запомню эти девять слов. Но у меня есть большой codebase, который я хочу перенести, например, с angular и мне их придется везде править.
saggid
01.10.2015 18:29Так ведь код, написанный для какой-то определённой библиотеки, всегда нуждался в правке, при переносе его на какую-либо другую библиотеку. По-другому и быть не может. Да и у Riot вообще своя идеология и свой уникальный подход к построению компонентов.
prog666
Есть ли возможность пре-компиляции на стороне сервера с целью отдачи первой страницы в виде html? Насколько я знаю сейчас это умеет только React из-за виртуального DOM.
tratotui
Из коробки библиотека особо ничего не умеет кроме MVVM — это ее и плюс и минус, но в свою очередь имеет ряд плагинов: ajax, routing, и.т.д. Я могу конечно ошибаться, заранее прошу прощения, но существует плагин github.com/vuejs/vue-component-compiler#user-content-registering-custom-pre-processors.
Rastishka
Пока нет, но автор в тикете обещал что в планах есть.
prog666
Тогда интересная тема, разве что плагинов под существующие решения больше, но я бы попробовал в каком-нибудь из проектов Vue.
Rastishka
Был не прав.
Нашел обсуждение github.com/yyx990803/vue/issues/114 — нет, не обещает. =(
Пишет что будет сложно на клиентсайде объединить сгенерированный на сервре DOM с вычисляемым на клиенте DOM, чтобы все осталось работоспособным.
prog666
Жаль…