Комментарии 37
3) Так можно напугать только тех, кто не знает Backbone (и десятки плагинов на любой вкус для связывания данных).
4) «сделаю, как знаю» — это, как правило «кое-как че-то притулил сбоку», см. пункты 5 и 7.
5) и 7) Тут недавно обсуждали, чем хороши и чем плохи фреймворки. Вот jQuery, например, тоже не накладывает ограничений, и теперь «джейквери» — это синоним «спагетти».
11)
У вас код прибегает к помощи ES6? «Не пиши меня, страшный программист, я ES6 на помощь позову!»
4) «сделаю, как знаю» — это, как правило «кое-как че-то притулил сбоку», см. пункты 5 и 7.
5) и 7) Тут недавно обсуждали, чем хороши и чем плохи фреймворки. Вот jQuery, например, тоже не накладывает ограничений, и теперь «джейквери» — это синоним «спагетти».
11)
результирующий код, как правило, выглядит достаточно компактно, особенно прибегая к помощи ECMAScript 6
У вас код прибегает к помощи ES6? «Не пиши меня, страшный программист, я ES6 на помощь позову!»
Так можно напугать только тех, кто не знает Backbone (и десятки плагинов на любой вкус для связывания данных).
Уверен, что костыли найдутся для любого неудачного решения.
«сделаю, как знаю» — это, как правило «кое-как че-то притулил сбоку», см. пункты 5 и 7.
Тут всё зависит от того, насколько вы хороший программист. Вся соль в том, что вам не требуется идти на StackOverflow или на Тостер за ответом на вопрос, как прикрутить скрипт X к фреймворку Y. Матрешка по умолчанию работает со всеми возможными библиотеками (за исключением каких-нибудь хитрых решений, о которых я пока не знаю). Но это не новость, тот же Backbone умеет это делать.
Тут недавно обсуждали, чем хороши и чем плохи фреймворки. Вот jQuery, например, тоже не накладывает ограничений, и теперь «джейквери» — это синоним «спагетти».
Я не совсем понял этот пункт. Во-первых jQuery — не фреймворк. Во-вторых, не понимаю, почему она (библиотека) у вас ассоциируется со спагетти.
Тут всё зависит от того, насколько вы хороший программист.
Ну вот о чем и речь. В более жестком окружении (читай: во фреймворке) плохой программист будет ограничен в своих возможностях наговнякать спагетти-кода. А хороший программист и так не заблудится, кто же спорит.
Изобретать архитектуру, конечно, интересно. Но иногда нужно просто быстро сделать прототип и не думать, как его изящнее организовать.
Уверен, что костыли найдутся для любого неудачного решения.
Ну да, все контрибьюторы в Backbone — дураки, а вы один Д'Артаньян в белом.
Во-первых jQuery — не фреймворк.
Матрешка — тоже не фреймворк (как и Backbone).
Во-вторых, не понимаю, почему она (библиотека) у вас ассоциируется со спагетти.
Полтора года назад в Москве была конфа по jQuery, в конце была Q&A сессия с разработчиками. Приз за лучший вопрос получил парень, который спросил, почему код на jQuery «такие макароны».
Я честно не понимаю, почему она у вас не ассоциируется со спагетти-кодом.
программист будет ограничен в своих возможностях
У нас совершенно разные взгляды на программирование в принципе. Мне с института не нравились жесткие обязательства по структуре кода.
Ну да, все контрибьюторы в Backbone — дураки, а вы один Д'Артаньян в белом.
Я нигде не говорил, что кто-то дурак.
Приз за лучший вопрос получил парень, который спросил, почему код на jQuery «такие макароны».
Это очень слабый аргумент.
Я честно не понимаю, почему она у вас не ассоциируется со спагетти-кодом.
Я много лет использовал jQuery (хотя сейчас в нем нет никакой нужды) и не встречал макарон, вызванных не криворукостью разработчика, а проблемами в библиотеке. Я не защищаю jQuery, просто пытаюсь понять, что вы мне хотите сказать в контексте Матрешки.
Не поймите меня превратно, мне нравится идея простой библиотеки для связывания. Меня смущают ваши аргументы.
Даже, может быть, я попробую сделать что-то на Матрешке (+ Backbone:)).
Даже, может быть, я попробую сделать что-то на Матрешке (+ Backbone:)).
В документации Матрешки много примеров, где JS обработчики прибивается гвоздями (или данные биндятся) селекторами к HTML разметке.
В ангуляре, например, директивы как раз выполняют роль клея между логикой контроллера и представлением.
Простой пример: в проекте решили убрать часть представления — убрали вывод имени пользователя.
В ангуляре: убрать часть HTML кода для вывода имени пользователя. Матрешка: убрать часть HTML кода для вывода имени пользователя, почистить логику, где биндится имя пользователя из данных к HTML селектору.
Или в Матрешке не так? Пожалуйста, поправьте.
В ангуляре, например, директивы как раз выполняют роль клея между логикой контроллера и представлением.
Простой пример: в проекте решили убрать часть представления — убрали вывод имени пользователя.
В ангуляре: убрать часть HTML кода для вывода имени пользователя. Матрешка: убрать часть HTML кода для вывода имени пользователя, почистить логику, где биндится имя пользователя из данных к HTML селектору.
Или в Матрешке не так? Пожалуйста, поправьте.
НЛО прилетело и опубликовало эту надпись здесь
Не всегда необходимо заниматься чисткой логики в ангуляре.
Пример: массив объектов, у каждого объекта есть свойство «user». Этот массив попадает в код клиентского приложения через аякс-запрос, кладется в скоуп контроллера, через скоуп попадает во вью, где происходит перебор элементов и вывод списка этих записей. Мне достаточно убрать «user» в коде серверного приложения и из HTML разметки представления.
Пример: массив объектов, у каждого объекта есть свойство «user». Этот массив попадает в код клиентского приложения через аякс-запрос, кладется в скоуп контроллера, через скоуп попадает во вью, где происходит перебор элементов и вывод списка этих записей. Мне достаточно убрать «user» в коде серверного приложения и из HTML разметки представления.
НЛО прилетело и опубликовало эту надпись здесь
Аякс запрос трогать не нужно — запросом мы получаем список записей, у каждой записи было проставлено свойство «user», которое хранило информацию о пользователе. Свойство «user» (для каждой записи) убрали на серверной стороне — на клиентской убрали HTML разметку, отвечающую за вывод пользователя для каждой записи. Логику JavaScript контроллера не трогали.
Именно так. Но проблема с «убиранием» части логики мне кажется надуманной.
Возможно, не спорю.
app.bindNode( 'x', '.my-input' );Ладно «убирание», но ведь таким образом мы ставим контроллер в зависимость от шаблона. Здесь программист должен заранее подумать какой селектор потом будет или уже есть в шаблоне. Как минимум, лучше объявить соглашение: Связь «свойство-елемент» создается через селектор, например, ".bind-NAME". Тогда можно будет и «автоматом» связывать шаблон и модель, как это обычно делается, а на случай экзотического поведения уже вручную связывать некоторые свойства с элементами по селектору. Скажем такое поведение уже на порядок лучше:
<input type="text" class="bind-foo">
<script>
var app = new Matreshka({
foo : null
});
app.foo = 'Двустороннее связывание данных в JS? Серьезно?';
</script>
НЛО прилетело и опубликовало эту надпись здесь
Шаблонизатора в ближайшем времени точно не будет.
Я делал два проекта, в которых используется такая логика (требование клиента). В итоге, получился совершенно другой фреймворк, заточенный под узкую задачу проекта.
Я делал два проекта, в которых используется такая логика (требование клиента). В итоге, получился совершенно другой фреймворк, заточенный под узкую задачу проекта.
А при чём здесь шаблонизатор? Я говорю о более чистом разделение ответственности, ведь иначе пример из главной похож больше не на «JavaScript фреймворк для программистов», а на «JavaScript фреймворк для верстальщиков». Никаким образом нельзя смешивать селекторы для стилизации и селекторы для связывания. И последние должны также выделяться префиксом для явности.
По 3-ему пункту, как я понял это сделано при помощи Object.observe, то есть мы имеем ситуация что приложение не будет работать в «немного более старых браузерах чем хотелось бы». Или тут есть dirty check как в angular.js (про производительность которого вообще стоит молчать)?
Итого: мне кажется современный мир пока не может ничего лучше предложить, чем двойное связывание через события
Итого: мне кажется современный мир пока не может ничего лучше предложить, чем двойное связывание через события
Тут используются акцессоры, добавленные с помощью Object.defineProperty. А эта функция работает везде, включая ИЕ8. dirty check — это очень плохая идея.
Или тут есть dirty check как в angular.js (про производительность которого вообще стоит молчать)?А чего молчать, один из самых быстрых фреймворков, гораздо быстрее чем knockout.js который основан на observable подходе, в матрешке принцип тот же, но поверх Object.defineProperty.
Кстати не знаете какие фреймворки уже используют Object.observe (не считая Angular Light и Angular 2, кстати в последний вроде ещё не «вкрутили»)?
Андрей, вы занимаетесь продвижение фреймворка за рубежом?
Я спрашиваю потому, что кроме функциональности фреймворка многих интересует его популярность. Если мы делаем свои стартапы, то можем делать, что хотим, но если мы работаем на аутсорсе, мы должны быть уверенны, что делаем качественный продукт. Один из критериев качества, я считаю, является возможность легко передать разработку проекта другой команде. Так вот, какие риски столкнуться с тем, что заказчик не найдет специлистов, знабщих этот фреймворк за приделами бывшего СНГ?
Я спрашиваю потому, что кроме функциональности фреймворка многих интересует его популярность. Если мы делаем свои стартапы, то можем делать, что хотим, но если мы работаем на аутсорсе, мы должны быть уверенны, что делаем качественный продукт. Один из критериев качества, я считаю, является возможность легко передать разработку проекта другой команде. Так вот, какие риски столкнуться с тем, что заказчик не найдет специлистов, знабщих этот фреймворк за приделами бывшего СНГ?
Это легко понять по числу форков и issues на гитхабе как мне кажется.
Это легко понять по числу форков и issues на гитхабе как мне кажется.
Понимаю вас… Документация пишется на двух языках, это сделано как раз для разработчиков из-за бугра. Будет опубликовано несколько статей англоязычных ресурсах. Европа и США — очень важные приоритеты проекта. Но буду откровенен, полноценного продвижения, на сегодняшний день, нет.
С другой стороны, Матрешка — библиотека основанная на прототипном наследовании, с которым должен быть знаком любой JS разработчик. Единственное, что действительно нужно знать — это то, как связывать свойства и ноды (метод bindNode, средняя сложность), как ловить изменения данных (метод on, который очень похож на одноименный метод из Backbone, малая сложность) и как рендерить коллекции (сложность выше среднего). Остальное не настолько важно. Здесь нет каких-нибудь специфичных концепций, модных аббревиатур и разглагольствований, так что программисту, никогда не имевшему дела с Матрешкой, не должно составить большого труда разобраться с основами.
С другой стороны, Матрешка — библиотека основанная на прототипном наследовании, с которым должен быть знаком любой JS разработчик. Единственное, что действительно нужно знать — это то, как связывать свойства и ноды (метод bindNode, средняя сложность), как ловить изменения данных (метод on, который очень похож на одноименный метод из Backbone, малая сложность) и как рендерить коллекции (сложность выше среднего). Остальное не настолько важно. Здесь нет каких-нибудь специфичных концепций, модных аббревиатур и разглагольствований, так что программисту, никогда не имевшему дела с Матрешкой, не должно составить большого труда разобраться с основами.
Готовлю новые материалы и случайно увидел ваш комменитарий.
Статьи переведены и опубликованы. Посмотрим, что из этого получится.
Статьи переведены и опубликованы. Посмотрим, что из этого получится.
Второй и пятый пункты очень понравились, загорелся пробовать.
По популярности фреймворка важный пункт. Работодатель знает Ангуляр, Бекбон, а я приду и скажу, что предпочитаю Матрёшку. Как-то не хочется их этим шокировать.
И название лучше сменить, мы же не видим у американцев фреймворки «Дядя Сэм» или «Звёздно-полосатый фреймворк», потому что они не выстрелят. Для иностранного потребителя матрёшка это длинно и непонятно, а для российского — отдаёт квасным патриотизмом и ассоциируется с детской игрушкой. Именно с квасным, вообще я за патриотизм, не подумайте.
Большой респект вам за начинание, очень правильные идеи положены в основу. Хочется верить, что всё у вас с этим фреймворком будет хорошо.
По популярности фреймворка важный пункт. Работодатель знает Ангуляр, Бекбон, а я приду и скажу, что предпочитаю Матрёшку. Как-то не хочется их этим шокировать.
И название лучше сменить, мы же не видим у американцев фреймворки «Дядя Сэм» или «Звёздно-полосатый фреймворк», потому что они не выстрелят. Для иностранного потребителя матрёшка это длинно и непонятно, а для российского — отдаёт квасным патриотизмом и ассоциируется с детской игрушкой. Именно с квасным, вообще я за патриотизм, не подумайте.
Большой респект вам за начинание, очень правильные идеи положены в основу. Хочется верить, что всё у вас с этим фреймворком будет хорошо.
НЛО прилетело и опубликовало эту надпись здесь
Балалайка в матрёшку уже встроена.
VODKA уже застолбили ребята из Postgres в качестве названия движка индексов для JSONB. Пруф.
Просто название очень хорошо подходит для фреймворка, умеющего наследование. Балалайка — это, скорее, шуточное название, взятое, как логическое продолжение названия фреймворка. Vodkajs, к сожалению, было уже занято :)
З. Ы. Матрешка — японская игрушка, с немного измененным дизайном.
З. Ы. Матрешка — японская игрушка, с немного измененным дизайном.
Матрешка не заставляет использовать определенную структуру кода, и не принуждает пользоваться хорошими, но, возможно, не самыми удачными решениями. Вы сами выбираете паттерны проектирования и структурирования приложения. Хоть Матрешка и позиционируется, как фреймворк, но, скорее, это библиотека, уменьшающая объем предстоящей работы.Это мудро и честно. Хотя и требует большей дисциплины.
НЛО прилетело и опубликовало эту надпись здесь
Киньте пример. Документация к Матрешке и есть одностраничное приложение с несколькими страницами (пока без рефакторинга).
НЛО прилетело и опубликовало эту надпись здесь
Нет, хорошие вопросы. Документация сделана нетрадиционным способом, так как HTML сгенерирован заранее (для поисковых систем, производительности и работы оффлайн). Это не «общий» случай использования Матрешки. Я активно думаю над тем, как еще расширить примеры к Матрешке новыми примерами.
Тут два варианта:
1. Иметь один объект. Убирать старые байндинги, добавлять новые, когда DOM дерево меняется.
2. Иметь несколько объектов и за каждым закрепить своё дерево DOM. Этот вариант проще в реализации, он не требует уничтожения байндингов.
Сбросьте какой-нибудь пример, реализованный на базе другого фреймворка, я смотгу ответить конкретнее.
… Потом dom с этим input-ом удалил со страницы (загрузилась новая страница 2, которая переформировала ...
Тут два варианта:
1. Иметь один объект. Убирать старые байндинги, добавлять новые, когда DOM дерево меняется.
2. Иметь несколько объектов и за каждым закрепить своё дерево DOM. Этот вариант проще в реализации, он не требует уничтожения байндингов.
Сбросьте какой-нибудь пример, реализованный на базе другого фреймворка, я смотгу ответить конкретнее.
НЛО прилетело и опубликовало эту надпись здесь
Такой пример совершенно не подходит для демонстрации возможностей Матрешки. Так что давайте вы попробуете, а я отвечу на вопросы, если у вас возникнут проблемы.
Я уже писал раньше (в первых статьях о Матрешке), что для простых сайтов (не приложений или приложений, но с минимальным функционалом) лучше использовать Ангуляр. Это лучшее решение для небольших прототипов и малофункциональных приложений.
Я уже писал раньше (в первых статьях о Матрешке), что для простых сайтов (не приложений или приложений, но с минимальным функционалом) лучше использовать Ангуляр. Это лучшее решение для небольших прототипов и малофункциональных приложений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
(Архив) 10 причин попробовать Матрешку