Ну как я и писал это пример из реального проекта «Пятнашки» (ЗОЖ сайт) над которым сейчас работаю — поэтому сделанно так как видит дизайнер а не потому что удобно сделать с библиотечкой. Я специально брал реальные требования и дизайн потому как всегда черт в мелочах — типа можно сделать очень легко, но не так как хочет дизайнер и тогда это никому не нужно.
Примеры на самом деле не одинаковые.
Форма была отдельно от коммента. По множественному нажатию на «Добавить комментарий» не додовлялось безконечные формы ответа. Что бы форма ответа была снизу и сверху по условию. Анимация на комент была другая и именно она должна бять. Дата форматировалась в «минут назад» и еще много мелочей. У вас получилось меньше кода и локаничней потому как вы упростили саму задачу.
Если вы не против я утяну к себе ваш пример и доделаю что бы они были действительно одинаковыми что бы использовать в сравнении vs.?
По поводу нехватки в Ractive фич. Данные нужно обновлять через set — если не нужно поддерживать IE8 и меньше — то можно поставить magic mode и он будет использовать геттеры сеттеры что бы слушать уведомаления о изменении. и можно будет писать var comment.text = 'нет'.
Про «remove» согласен нехватает. Делать racitve.set('prop',null) странно.
getRactivePathByDiv — костыль не нужен, посмотрите как передается текущий объект e.context в моем примере. так же можно делать так
on-click='doWhatever,{{object}}' и вторым параметрав в doWhatever будет object.
По поводу if — и блоков которые не видны, тоже все есть. посмотрите мой пример там есть {{#if}} и {{#replys.comments > 0}}
Возможно вы пользовались старой версией либы. Сейчас все проблемы описанные решены.
И так же согалсен что знаметиные родители с большой командой поддержки — это тоже +.
Вложенность максимум что я нашол — 3. init() -> on('save') -> then(); если я чет не вижу поправте. Учитывая что практически весь код сконцентрирован в init (что может быть не есть феншуй но и не преступленее точно, скорее инкапсуляция для компонента) — то можно смело сказать что вложенность максимум 2. on('save',callback) -> then(callback).
ИМХО не так плохо, коллбек на ивент, коллбек на сетевой запрос. Поправте меня пожалуйста если я что то пропускаю.
Но для меня опять повторюсь ключевым отличием или преимуществом являеться простота Ractive.
т.е. нет никаких внедрение зависимости, котроллеров, $scopes, атрибутов который работают не прозрачно и т.д.
Документацию сложно (может быть это только с моим маленьким мозгом) читать и понимать так как воводиться огромное количество новых концепций которые не интуитивные.
Для того что бы начать писать сложные UI на Ractive нужно 40-50 мин времени и понимать как UI бить на компоненты. Причем не компоненты как это видит Ractive… а на обычные web components.
Покопавшись еще чуть чуть я понял что не правильно понимал что такое «dirty-checking».
Я думал что он имеет ввиду что «кода что то изменилось мы пересоздаем весь дом». На самом деле это значит (я так думаю) «Мы отслеживаем все изменения я в данном scope и по всем дерективам проверяем поменялось ли значение по отношению к преведущему или нет и если поменялось то нужно обновлять данный кусок DOM».
и тут java.dzone.com/articles/improving-angular-dirty
docs.angularjs.org/guide/scope ( Sope Life Cycle);
After evaluating the expression, the $apply method performs a $digest. In the $digest phase the scope examines all of the $watch expressions and compares them with the previous value. This dirty checking is done asynchronously. This means that assignment such as $scope.username=«angular» will not immediately cause a $watch to be notified, instead the $watch notification is delayed until the $digest phase. This delay is desirable, since it coalesces multiple model updates into one $watch notification as well as it guarantees that during the $watch notification no other $watches are running. If a $watch changes the value of the model, it will force additional $digest cycle.
Ractive — делает дерево зависимостей и обновляет только тот DOM который зависит, т.е. он трекает кто от чего зависит и меняет это только в том случае если что то поменялось в его дереве. О изменениях в дереве он узнает через ractive.set(). ( кстати именно поэтому ангулар может работать без set);
Я был не прав в том что думал что ангулар всегда пересоздает весь DOM. Но он полностью просчитывает (dirty checking) состояние отображение на каждое изменение что дорого. Как директх.
Интересные ребяра, правда я пока не могу понять в чем их фишка точнее отличее от Ractive. Они говорят что они вдохновлялись Angular и Ractive. Но из обзора ме могу понять что они делают по другому. Строят паралельный DOM? Перерисовывают весь UI?
Я так понял, тоже самое что Ractive (паралельный DOM + api инстанса) но все цепляется через дерективы как у Angular но все равно с пимисью mustache?
Но суть в том что если вы удалили руками ноду то она собственно умрет. Ангулал не перисовывает список а пытаеться искать в доме атирбуты (все) и поменять его. Не находя атрибут он его не меняет. Вобщем ничего страшного.
Что бы понять что он перерисовывет весь дом попробуйте в вашем методе добавить елемент в array.
Я думаю что если вы работаете над небольшим проетктом вам не нужен ангулар. Если вы работаете над действительно большим вы не сможете его применять.
Хотя на самом деле я думаю что если вы уже выучили Ангулар — и не работаете в компании которая делает денамический интерфейс для миллионов пользователей — забейте на все и пользуйтесь Ангуляр — реально хорошая штука если ее постигнуть.И авторы правы (ссылка вверху) врядли вы сталкнетесь с проблемой производительности. Если вы еще не потратили моного времени на изучение Ангулара — попробуйте полностью понять за 30 минут Ractive и улыбка непременно окажеться у вас на лице. ИМХО.
Backbone — если коротко то это модель\коллекции моделей где стандартизированно апи по взимодействию с сервером. на кажое изменение модели они кидают ивенты. Так же есть вьюшки которые просто группируют куски DOM и метод render который вставляет его в DOM.
Дальше вы связываете render метод (биндите) разных вьешек с разными моделями. И наступет радость — вы обновили модель — поменялась вьюшка.
Минусы такого подхода в том что описание вьюшек не декларативное и приходиться проверять состояние приложения, и второе либо приходиться делать ооочень маленькие вьшечки пипушечки чуть ли не накжое проперти модели либо приходиться перерисовывать много дома, который не изменился.
Ну и самое главное в бекбоне надо порядок больше кода для того что бы это связать воедино.
Ractive же говорит опишите темплейт и я там буду менять только то что меняеться в модели. Очень точечно и за один цикл. Никаких ивентов… биндингов и прочего.
Из возможных минусов — Ractive занимаеться только UI. Больше он ничего не умеет… ни моделью управлять… ни роутера нет… ни валидаторов… вам прийдеться искать что то для этих задачь. Для некотрых это + для некоторых это -.
107KB vs 137BK действительно Angular легче в размере.
Но они используют 2 разных подхода к решению одной и той же задачи. Это не просто 2х сторонний биндинг.
Опять же хочу как нить написать отедльный пост и попытаться сравнить.
Если кратко: если вы пишете большое приложение… на самом деле большое, или пишите UI под мобилы — вы сталкнетесь с проблемами производительности в Angular. Он проверяет на любое изменение все дерево зависимостей что приводит к плохим результатам в больших приложухах, и самое главное не понятно что с этим всем делать. C паралельным DOM таких проблем нет (точнее они меньше) потому что меняеться только то что должно поменяться + вполне понятно как оптимизировать, отследив что ререндариться.
Если у вас маленькое приложение то учить и использовать Ангулар — как вы сказали из пушки по воробьям. А изучение Ангулара та еще радость.
+ субъективное мое мнение. Мне больше нравиться работать с маленькими (всмысле зоны ответственности) библеотеками сконцентрированными на какой то функции и группировать с другими библеотеками и смотреть что в данный момент под данное ТЗ, наилучшим образом решает задачу. Поэтому мне не нравиться (субъектвино) ангуляр который имеет мнение обо всем.
Cпасибо за ссылки. Очень похожие проекты. Нужно поиграться обязательно. Хочу еще написать обзор Ractive vs. React… может чуть раширить список реактивненького.
Я правильно понял идею: у вас есть данные вы пересываете сетеры\геттеры на модели и в них пишите как меняеться UI? добовляя, убирая и измения елементы? Судя по имплементации ToDo это больше похоже на Backbone чем на Ractive
Да Ractive кроме UI вообще ничем не занимается. Выбирайте любой который вам нравится\знаком. Ractive очень легко связывать с другими тулами… начиная от jquery плагинов и заканчивая чем угодно. Мы например берем модель и роутер из Backbone.
Там идея в том что ractive сам занимаеться делегированием. Поэтому фактически не нужно самим это делать. Там есть крайние случае, но это не очень инетерсная тема.
Это это совсем не Ангуляр. т.е. в чем то конечно похоже, а в чем то даже писался с него. Но есть очень ключевые различия.
Ссылку кину как сделаю. Спасибо.
Примеры на самом деле не одинаковые.
Форма была отдельно от коммента. По множественному нажатию на «Добавить комментарий» не додовлялось безконечные формы ответа. Что бы форма ответа была снизу и сверху по условию. Анимация на комент была другая и именно она должна бять. Дата форматировалась в «минут назад» и еще много мелочей. У вас получилось меньше кода и локаничней потому как вы упростили саму задачу.
Если вы не против я утяну к себе ваш пример и доделаю что бы они были действительно одинаковыми что бы использовать в сравнении vs.?
По поводу нехватки в Ractive фич. Данные нужно обновлять через set — если не нужно поддерживать IE8 и меньше — то можно поставить magic mode и он будет использовать геттеры сеттеры что бы слушать уведомаления о изменении. и можно будет писать var comment.text = 'нет'.
Про «remove» согласен нехватает. Делать racitve.set('prop',null) странно.
getRactivePathByDiv — костыль не нужен, посмотрите как передается текущий объект e.context в моем примере. так же можно делать так
on-click='doWhatever,{{object}}' и вторым параметрав в doWhatever будет object.
По поводу if — и блоков которые не видны, тоже все есть. посмотрите мой пример там есть {{#if}} и {{#replys.comments > 0}}
Возможно вы пользовались старой версией либы. Сейчас все проблемы описанные решены.
И так же согалсен что знаметиные родители с большой командой поддержки — это тоже +.
ИМХО не так плохо, коллбек на ивент, коллбек на сетевой запрос. Поправте меня пожалуйста если я что то пропускаю.
т.е. нет никаких внедрение зависимости, котроллеров, $scopes, атрибутов который работают не прозрачно и т.д.
Документацию сложно (может быть это только с моим маленьким мозгом) читать и понимать так как воводиться огромное количество новых концепций которые не интуитивные.
Для того что бы начать писать сложные UI на Ractive нужно 40-50 мин времени и понимать как UI бить на компоненты. Причем не компоненты как это видит Ractive… а на обычные web components.
Покопавшись еще чуть чуть я понял что не правильно понимал что такое «dirty-checking».
Я думал что он имеет ввиду что «кода что то изменилось мы пересоздаем весь дом». На самом деле это значит (я так думаю) «Мы отслеживаем все изменения я в данном scope и по всем дерективам проверяем поменялось ли значение по отношению к преведущему или нет и если поменялось то нужно обновлять данный кусок DOM».
и тут java.dzone.com/articles/improving-angular-dirty
docs.angularjs.org/guide/scope ( Sope Life Cycle);
After evaluating the expression, the $apply method performs a $digest. In the $digest phase the scope examines all of the $watch expressions and compares them with the previous value. This dirty checking is done asynchronously. This means that assignment such as $scope.username=«angular» will not immediately cause a $watch to be notified, instead the $watch notification is delayed until the $digest phase. This delay is desirable, since it coalesces multiple model updates into one $watch notification as well as it guarantees that during the $watch notification no other $watches are running. If a $watch changes the value of the model, it will force additional $digest cycle.
Ractive — делает дерево зависимостей и обновляет только тот DOM который зависит, т.е. он трекает кто от чего зависит и меняет это только в том случае если что то поменялось в его дереве. О изменениях в дереве он узнает через ractive.set(). ( кстати именно поэтому ангулар может работать без set);
Я был не прав в том что думал что ангулар всегда пересоздает весь DOM. Но он полностью просчитывает (dirty checking) состояние отображение на каждое изменение что дорого. Как директх.
Я так понял, тоже самое что Ractive (паралельный DOM + api инстанса) но все цепляется через дерективы как у Angular но все равно с пимисью mustache?
Кстати не подходит если нужно поддерижвать IE8
Но суть в том что если вы удалили руками ноду то она собственно умрет. Ангулал не перисовывает список а пытаеться искать в доме атирбуты (все) и поменять его. Не находя атрибут он его не меняет. Вобщем ничего страшного.
Что бы понять что он перерисовывет весь дом попробуйте в вашем методе добавить елемент в array.
О магия если вы удалите елемент из дом он вернеться. Чего не произойдет в Рактив.
Авторы англар утверждают что «вообще это не важно» — stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933
Я думаю что если вы работаете над небольшим проетктом вам не нужен ангулар. Если вы работаете над действительно большим вы не сможете его применять.
Хотя на самом деле я думаю что если вы уже выучили Ангулар — и не работаете в компании которая делает денамический интерфейс для миллионов пользователей — забейте на все и пользуйтесь Ангуляр — реально хорошая штука если ее постигнуть.И авторы правы (ссылка вверху) врядли вы сталкнетесь с проблемой производительности. Если вы еще не потратили моного времени на изучение Ангулара — попробуйте полностью понять за 30 минут Ractive и улыбка непременно окажеться у вас на лице. ИМХО.
Backbone — если коротко то это модель\коллекции моделей где стандартизированно апи по взимодействию с сервером. на кажое изменение модели они кидают ивенты. Так же есть вьюшки которые просто группируют куски DOM и метод render который вставляет его в DOM.
Дальше вы связываете render метод (биндите) разных вьешек с разными моделями. И наступет радость — вы обновили модель — поменялась вьюшка.
Минусы такого подхода в том что описание вьюшек не декларативное и приходиться проверять состояние приложения, и второе либо приходиться делать ооочень маленькие вьшечки пипушечки чуть ли не накжое проперти модели либо приходиться перерисовывать много дома, который не изменился.
Ну и самое главное в бекбоне надо порядок больше кода для того что бы это связать воедино.
Ractive же говорит опишите темплейт и я там буду менять только то что меняеться в модели. Очень точечно и за один цикл. Никаких ивентов… биндингов и прочего.
Из возможных минусов — Ractive занимаеться только UI. Больше он ничего не умеет… ни моделью управлять… ни роутера нет… ни валидаторов… вам прийдеться искать что то для этих задачь. Для некотрых это + для некоторых это -.
Но они используют 2 разных подхода к решению одной и той же задачи. Это не просто 2х сторонний биндинг.
Опять же хочу как нить написать отедльный пост и попытаться сравнить.
Если кратко: если вы пишете большое приложение… на самом деле большое, или пишите UI под мобилы — вы сталкнетесь с проблемами производительности в Angular. Он проверяет на любое изменение все дерево зависимостей что приводит к плохим результатам в больших приложухах, и самое главное не понятно что с этим всем делать. C паралельным DOM таких проблем нет (точнее они меньше) потому что меняеться только то что должно поменяться + вполне понятно как оптимизировать, отследив что ререндариться.
Если у вас маленькое приложение то учить и использовать Ангулар — как вы сказали из пушки по воробьям. А изучение Ангулара та еще радость.
+ субъективное мое мнение. Мне больше нравиться работать с маленькими (всмысле зоны ответственности) библеотеками сконцентрированными на какой то функции и группировать с другими библеотеками и смотреть что в данный момент под данное ТЗ, наилучшим образом решает задачу. Поэтому мне не нравиться (субъектвино) ангуляр который имеет мнение обо всем.
Это это совсем не Ангуляр. т.е. в чем то конечно похоже, а в чем то даже писался с него. Но есть очень ключевые различия.
Почитать можно здесь blog.ractivejs.org/posts/whats-the-difference-between-angular-and-ractive/
type='ractive/text'(или любое другое но не javascript или пустое) а то браузер будет пытаться запустить ваш темплейтвсе темплейты рактива лежат в отдельных файлах что хорошо. twig тоже судя по всему так умеет.