Как подметили в комментариях ниже, эти тесты не совсем корректны, и Ангуляр, при определенных условиях, может работать быстрее всех (хотя не могу судить).
Такой пример совершенно не подходит для демонстрации возможностей Матрешки. Так что давайте вы попробуете, а я отвечу на вопросы, если у вас возникнут проблемы.
Я уже писал раньше (в первых статьях о Матрешке), что для простых сайтов (не приложений или приложений, но с минимальным функционалом) лучше использовать Ангуляр. Это лучшее решение для небольших прототипов и малофункциональных приложений.
Нет, хорошие вопросы. Документация сделана нетрадиционным способом, так как HTML сгенерирован заранее (для поисковых систем, производительности и работы оффлайн). Это не «общий» случай использования Матрешки. Я активно думаю над тем, как еще расширить примеры к Матрешке новыми примерами.
… Потом dom с этим input-ом удалил со страницы (загрузилась новая страница 2, которая переформировала ...
Тут два варианта:
1. Иметь один объект. Убирать старые байндинги, добавлять новые, когда DOM дерево меняется.
2. Иметь несколько объектов и за каждым закрепить своё дерево DOM. Этот вариант проще в реализации, он не требует уничтожения байндингов.
Сбросьте какой-нибудь пример, реализованный на базе другого фреймворка, я смотгу ответить конкретнее.
Решил для небольшой тренеровки после обеда написать отдельную функцию bindNode.
Вот, если вам интересно:
window.bindNode = function bindNode( object, key, node, binder ) {
var value = object[ key ];
Object.defineProperty( object, key, {
get: function() {
return value;
},
set: function( v ) {
binder.setValue.call( node, v );
}
});
node.addEventListener( binder.on, function() {
value = binder.getValue.call( node );
});
};
Функция поддерживает только один набор аргументов, аргумент node должен быть DOM нодой, нет стандартных байндеров и пр., но вы можете сами дописать, это не трудно.
Связывание тут реализуется достаточно просто. Любой программист со средним опытом может реализовать standalone функцию bindNode с помощью Object.defineProperty и addEventListener.
Но вы же хотите привлечь внимание, назовите причины по которым это стоит сделать с оглядкой на упомянутый крутой фрэймворк.
Неужели вам не хочется понять в сравнении преимущества своего детища? Я же не издеваюсь ни капли.
Я вряд ли когда-то буду говорить, что такой-то фреймворк плохой, а этот лучше всех. Почему стоит использовать или не использовать Матрешку, решаете вы сами. Главная задача разработчика любого свободного инструмента — дать возможность определиться, нужно ли его использовать или нет. Мне кажется, здесь с этим всё в порядке: есть сайт, есть «рекламирующие» тексты, есть документация, есть примеры (в том числе и средних размеров: TodoMVC).
Я уже год назад отказался от поддержки IE < 8 и не собираюсь возвращаться и извращаться.
Просто название очень хорошо подходит для фреймворка, умеющего наследование. Балалайка — это, скорее, шуточное название, взятое, как логическое продолжение названия фреймворка. Vodkajs, к сожалению, было уже занято :)
З. Ы. Матрешка — японская игрушка, с немного измененным дизайном.
Понимаю вас… Документация пишется на двух языках, это сделано как раз для разработчиков из-за бугра. Будет опубликовано несколько статей англоязычных ресурсах. Европа и США — очень важные приоритеты проекта. Но буду откровенен, полноценного продвижения, на сегодняшний день, нет.
С другой стороны, Матрешка — библиотека основанная на прототипном наследовании, с которым должен быть знаком любой JS разработчик. Единственное, что действительно нужно знать — это то, как связывать свойства и ноды (метод bindNode, средняя сложность), как ловить изменения данных (метод on, который очень похож на одноименный метод из Backbone, малая сложность) и как рендерить коллекции (сложность выше среднего). Остальное не настолько важно. Здесь нет каких-нибудь специфичных концепций, модных аббревиатур и разглагольствований, так что программисту, никогда не имевшему дела с Матрешкой, не должно составить большого труда разобраться с основами.
Я делал два проекта, в которых используется такая логика (требование клиента). В итоге, получился совершенно другой фреймворк, заточенный под узкую задачу проекта.
У нас совершенно разные взгляды на программирование в принципе. Мне с института не нравились жесткие обязательства по структуре кода.
Ну да, все контрибьюторы в Backbone — дураки, а вы один Д'Артаньян в белом.
Я нигде не говорил, что кто-то дурак.
Приз за лучший вопрос получил парень, который спросил, почему код на jQuery «такие макароны».
Это очень слабый аргумент.
Я честно не понимаю, почему она у вас не ассоциируется со спагетти-кодом.
Я много лет использовал jQuery (хотя сейчас в нем нет никакой нужды) и не встречал макарон, вызванных не криворукостью разработчика, а проблемами в библиотеке. Я не защищаю jQuery, просто пытаюсь понять, что вы мне хотите сказать в контексте Матрешки.
Так можно напугать только тех, кто не знает Backbone (и десятки плагинов на любой вкус для связывания данных).
Уверен, что костыли найдутся для любого неудачного решения.
«сделаю, как знаю» — это, как правило «кое-как че-то притулил сбоку», см. пункты 5 и 7.
Тут всё зависит от того, насколько вы хороший программист. Вся соль в том, что вам не требуется идти на StackOverflow или на Тостер за ответом на вопрос, как прикрутить скрипт X к фреймворку Y. Матрешка по умолчанию работает со всеми возможными библиотеками (за исключением каких-нибудь хитрых решений, о которых я пока не знаю). Но это не новость, тот же Backbone умеет это делать.
Тут недавно обсуждали, чем хороши и чем плохи фреймворки. Вот jQuery, например, тоже не накладывает ограничений, и теперь «джейквери» — это синоним «спагетти».
Я не совсем понял этот пункт. Во-первых jQuery — не фреймворк. Во-вторых, не понимаю, почему она (библиотека) у вас ассоциируется со спагетти.
Я уже писал раньше (в первых статьях о Матрешке), что для простых сайтов (не приложений или приложений, но с минимальным функционалом) лучше использовать Ангуляр. Это лучшее решение для небольших прототипов и малофункциональных приложений.
Тут два варианта:
1. Иметь один объект. Убирать старые байндинги, добавлять новые, когда DOM дерево меняется.
2. Иметь несколько объектов и за каждым закрепить своё дерево DOM. Этот вариант проще в реализации, он не требует уничтожения байндингов.
Сбросьте какой-нибудь пример, реализованный на базе другого фреймворка, я смотгу ответить конкретнее.
Тогда вместо
Можно писать
Тогда фреймворк уеньшится на 20%, по моим оценкам, что очень немного, при этом не отразившись на производительности. Поэтому, я не вижу в этом смысла.
Буду благодарен, если поделитесь опытом (здесь или в личке). Очень интересно.
bindNode.Вот, если вам интересно:
Функция поддерживает только один набор аргументов, аргумент node должен быть DOM нодой, нет стандартных байндеров и пр., но вы можете сами дописать, это не трудно.
jsbin.com/mabetap/2/edit?html,js,console,output
Введите
data.x = 'Hello world'в консоли.Тогда пропадет возможность использования всяких плюшек, типа делегированных событий, зависимостей свойств друг от друга и пр.
Я вряд ли когда-то буду говорить, что такой-то фреймворк плохой, а этот лучше всех. Почему стоит использовать или не использовать Матрешку, решаете вы сами. Главная задача разработчика любого свободного инструмента — дать возможность определиться, нужно ли его использовать или нет. Мне кажется, здесь с этим всё в порядке: есть сайт, есть «рекламирующие» тексты, есть документация, есть примеры (в том числе и средних размеров: TodoMVC).
Я и не против, но клиенты требуют.
Все фреймворки хороши по-своему. Вы мне ничего не должны :)
Когда ES6 будет использоваться повсеместно, так и сделаем. Сейчас нет в этом смысла. Многие даже не в курсе, что это такое.
К сожалению, это не так. Еще как минимум год разработчикам прийдется мучиться. Посмотрите любую статистику.
Полностью согласен. Но очень сложно соблюсти баланс между максимальной понятностью и функционалом примера.
З. Ы. Матрешка — японская игрушка, с немного измененным дизайном.
С другой стороны, Матрешка — библиотека основанная на прототипном наследовании, с которым должен быть знаком любой JS разработчик. Единственное, что действительно нужно знать — это то, как связывать свойства и ноды (метод bindNode, средняя сложность), как ловить изменения данных (метод on, который очень похож на одноименный метод из Backbone, малая сложность) и как рендерить коллекции (сложность выше среднего). Остальное не настолько важно. Здесь нет каких-нибудь специфичных концепций, модных аббревиатур и разглагольствований, так что программисту, никогда не имевшему дела с Матрешкой, не должно составить большого труда разобраться с основами.
Я делал два проекта, в которых используется такая логика (требование клиента). В итоге, получился совершенно другой фреймворк, заточенный под узкую задачу проекта.
У нас совершенно разные взгляды на программирование в принципе. Мне с института не нравились жесткие обязательства по структуре кода.
Я нигде не говорил, что кто-то дурак.
Это очень слабый аргумент.
Я много лет использовал jQuery (хотя сейчас в нем нет никакой нужды) и не встречал макарон, вызванных не криворукостью разработчика, а проблемами в библиотеке. Я не защищаю jQuery, просто пытаюсь понять, что вы мне хотите сказать в контексте Матрешки.
Уверен, что костыли найдутся для любого неудачного решения.
Тут всё зависит от того, насколько вы хороший программист. Вся соль в том, что вам не требуется идти на StackOverflow или на Тостер за ответом на вопрос, как прикрутить скрипт X к фреймворку Y. Матрешка по умолчанию работает со всеми возможными библиотеками (за исключением каких-нибудь хитрых решений, о которых я пока не знаю). Но это не новость, тот же Backbone умеет это делать.
Я не совсем понял этот пункт. Во-первых jQuery — не фреймворк. Во-вторых, не понимаю, почему она (библиотека) у вас ассоциируется со спагетти.