Почему именно Vue?

[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]

Жаль…

[kidar2]

хоть бы один пример кода

[xelam]

Много уроков и статей в нашем сообществе vk.com/vuejs + чат gitter.im/vuejs-ru/Discussion и официальный форум forum.vuejs.org

[lega]

Vue.js имеет более высокую производительность, потому что не использует «dirty checking». Angular становится более медленным, когда используются множество наблюдателей, потому что каждый раз при изменениях в области видимости, всем этим наблюдателям необходимо вычисляться снова. Vue.js не страдает от этого, потому что использует прозрачную систему отслеживания наблюдателей, поэтому все изменения вызываются самостоятельно, при наличии явных связанных зависимости.

Во первых, отсутствие «dirty checking» не гарантирует большую производительность (см. на тормозной knockout.js)

Во вторых, vue.js использует «dirty checking» или аналог (называйте как хотите), причем медленный (в Angular он отточен), вот перебор ватчей, а вот непосредственное изъятие значения на каждый ватч, да тут используется некоторое отслеживание зависимостей (которое не каждый раз используется), и поэтому такие штуки как вызов метода "{{fn()}}" тут работают криво, либо не работают вообще. Так же данные оборачиваются в геттеры/сеттеры что накладывает дополнительную нагрузку.

В третих, каждый фреймворк/библиотека быстрее «конкурента» в чем том своем, для каждого фреймворка можно сделать тест где он быстрее всех остальных. А производительность конечного проекта (в первую очередь) зависит от профессионализма разработчика, а не от фреймворка.

PS: Не могли бы вы добавить vue.js в местный хабра-бенчмарк, что-б увидеть на сколько он быстр.

[nuit]

>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.html

[lega]

Добавил Angular Light (сделал пулл-реквест) для теста, по скорости он получился один из самых быстрых, если не самый быстрый, у меня он чуть быстрее чем Angular 2 (40fps против 38fps у Angular 2).
Кстати для Angular 2, fps снижается со временем, за 2 мин он упал до 29, так же потребление памяти растет если смотреть внешними утилитами, возможно в нем есть утечка.

[nuit]

неплохой результат, вот для сравнения моя либа с реализацией виртуального дома kivi dbmonster.

И несмотря на кучу лишних операций при использовании виртуального дома вместо kvo, когда кол-во мутаций выставлено на 1%, подход с использованием виртуального дома может работать довольно таки быстро :)

[lega]

когда кол-во мутаций выставлено на 1%, подход с использованием виртуального дома может работать довольно таки быстро :)

Так же и с «dirty-checking», потому что основная нагрузка — DOM.
Для virtual-dom даже при малых изменениях, происходит сверка всего (большого куска) DOM, можно даже назвать это «dirty-checking dom». Поэтому React проигрывает Angular'у в этом тесте.

[nuit]

В kivi так же происходит дифф полного списка чилдренов, вместо точечных изменений.
React проигрывает потомучто там было сделано несколько плохих архитектурных решений, от которых сейчас довольно сложно избавиться.

[lega]

В kivi так же происходит дифф полного списка чилдренов, вместо точечных изменений.

Значит этот virtual-dom тоже будет медленным в большом DOM, который генерируют «крутые» дизайнеры. Те же формы, диалоги и пр. У меня попадаются задачи где 5 ватчей на 200 DOM элементов. Данный тест — «голая» таблица (~1900 ватчей), можно сказать идеальный тест для virtual-dom.
Опять же приходим к выводу, что брать virtual-dom из-за скорости смысла нет.

[nuit]

это идеальный тест для virtual-dom когда кол-во мутаций: 100%, идеальный тест для kvo когда: 1%, и плохой для dirty checking'а при любом кол-ве мутаций. И несмотря на самую худшую ситуацию для виртуального дома, когда изменения происходят только на 1% контента, каким-то образом либы, использующие kvo работают тормознее чем virtual dom.

[vird]

поэтому такие штуки как вызов метода "{{fn()}}" тут работают криво

Ок. Пускай такое работает.

1. В каком моменте фреймворк должен вызывать функцию fn?
2. Как фреймворк должен догадаться что значение поменялось?

[boolive]

Существенным недостатком для меня оказалась невозможность динамически добавить компоненты в страницу или просто поменять шаблон у компонента (получить его с сервера и скомпилировать). В приложении изначально должна быть определена иерархия компонентов, можно управлять только видимостью компонентов. Подгружать с сервера компоненты идеологически нельзя и автор не намерен это делать или принимать пул. реквесты по этой теме.

[lega]

Можете попробовать Angular Light, там есть возможность динамически добавлять директивы (компоненты), наследовать их и переименовывать, так же делать приватные наборы директив.

[stas404]

Как раз, собрался поковырять vue или riot — спасибо за комментарий, это действительно критичные нюансы, которые портят все впечатление.
На чем остановились в итоге? Или, быть может, есть какие кейсы по обходу этих обломных моментов?

[boolive]

Ни на чём, к сожалению. Надеялся Vue будет ненавязчивой, как они сами обещали, а получается наоборот.

[stas404]

В свою очередь, решил остановиться на более практичном и минималистичном Riot вместо Vue.

[vird]

http://vuejs.org/guide/components.html#Async-Components
Пока единственным недостатком явлется
http://webpack.github.io/docs/code-splitting.html

tldr: Webpack doesn’t support es6 modules, use require.ensure or require directly depending on which module format your transpiler creates.

Что плохо стыкуется с vue-loader'ом.

[saggid]

Советую Riot.js вместо всего, что было перечислено. Рендеринг на стороне сервера, очень простой механизм работы компонентов, при этом дающий делать все что может понадобиться. быстрый, маленький… использую уже почти год, очень доволен.

[plashenkov]

Кстати, на сайте Vue есть сравнение и с Riot: vuejs.org/guide/faq.html.
По какой-то причине не вошло в перевод. Переведу:

Riot 2.0 предоставляет схожую модель, основанную на компонентах (в Riot они называются тегами — “tag”), с минимальным и прекрасно спроектированным API. Я думаю, что Riot и Vue разделяют многие архитектурные принципы. Тем не менее, несмотря на то, что Vue является чуть более «тяжелым», чем Riot, он также предлагает некоторые существенные преимущества:

1. Настоящий условный рендеринг (Riot выводит все “if” ветки и просто прячет / показывает их);
2. Значительно более мощный ротер (API роутинга, предоставляемый Riot, просто крайне минимальный);
3. Более зрелая поддержка инструментов (см. webpack + vue-loader);
4. Система «эффектов перехода» (transition effect) (Riot не имеет таковой);
5. Лучший статус поддержки (на 31 августа 2015 г. Riot имеет 25 открытых багов, в то время как у Vue их 0);
6. Лучшая производительность (Riot, по факту, использует скорее прямую проверку (dirty checking), чем virtual-dom, и потому страдает от тех же проблем с производительностью, что и Angular).

От себя могу добавить, что автор Vue действительно крайне оперативно реагирует на задачи. Как-то я написал ему о встреченном баге, и он буквально тут же его исправил.

[saggid]

Это не существенные преимущества. Кое-где это просто различные подходы, а кое-где автор 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/1194

[nuit]

А ещё авторы riot.js отлично умеют врать «Absolutely the smallest possible amount of DOM updates and reflows» :)

[saggid]

Быть может, они и солгали где-то в другом месте, но данная фраза является чистой правдой: Riot.js обновляетв своих компонентах только то, что нуждается в обновлении, не затрагивая уже созданный ранее DOM. Более того, если вы будете рендерить ваши компоненты на сервере и на клиенте с одинаковыми параметрами, то при монтирования тега вообще ничего не будет обновлено.

Riot.js очень разумен в этом плане, и благодаря этому легко позволяет совмещать себя с любыми другими библиотеками, будь то jQuery или ещё что-либо, что будет изменять свойства ваших DOM элементов.

[nuit]

Я отлично знаю как работает riot.js, например советую взглянуть на реализацию each github.com/riot/riot/blob/master/lib/browser/tag/each.js

p.s. никому бы не советовал использовать riot.js в более менее серьёзных проектах

[saggid]

Я рад за вас, что вы отлично его знаете. Ну а я уже четыре проекта вместе с Riot.js написал, и я бы не сказал, что задачи, решаемые в ходе работы над этими проектами, были простыми, а конечный результат работы сайтов оказывался плохим.

Если вы под «более менее серьёзными проектами» подразумеваете какие-то сверхдинамичные веб-приложения, или еще что-то действительно очень требовательное к процессору — то конечно, возможно и есть смысл поискать что-то другое. Однако, на данный момент, во всех задачах разработки веб-интерфейсов, которыми я занимался, Riot.js прекрасно себя показал и убедил меня в адекватности его авторов более чем хорошо.

[plashenkov]

кроме указанной вами поддержки Вебпака

Не мной, а автором Vue. Я всего лишь перевел (так сказать, для полноты картины).
Я-то вообще «ровен» к разным библиотекам и ни в коем случае на агитирую за Vue и против Riot.
Спасибо за ваше дополнение. Лично я обязательно взгляну на Riot поближе.

[vird]

riotjs.com/api/#reserved-words
Пока бросилось вот это в глаза. В том же Angular тебя защищают при помощи $$ префикса. Дополнительный способ выстрелить себе в ногу.

[saggid]

Вы просто не знаете о том, что эти девять слов, перечисленных в этом разделе, вы в любом случае запомните наизусть уже через пару дней работы с данной библиотекой :) Эти слова — как переменные и методы родительского класса, от которого наследуются все ваши Riot-тэги. Любой ваш компонент будет использовать эти методы и переменные в своей работе.

В общем, это совершенно не относится к ситуациям с прострелами ног. Да и вообще, там всё настолько просто и элегантно сделано, что, в общем-то, чтобы запутаться там и реально прострелить себе ногу — надо очень постараться)

[vird]

Я-то запомню эти девять слов. Но у меня есть большой codebase, который я хочу перенести, например, с angular и мне их придется везде править.

[saggid]

Так ведь код, написанный для какой-то определённой библиотеки, всегда нуждался в правке, при переносе его на какую-либо другую библиотеку. По-другому и быть не может. Да и у Riot вообще своя идеология и свой уникальный подход к построению компонентов.

[Duke565]

Вакансия Vue.js разработчиком (80-130k rub/month).
Есть желающие?
Пишите на почту [e-mail]