Документация на русском
Github репозиторий
1. Чистый JavaScript и HTML
Многие фреймворки пытаются починить веб, создавая собственный язык программирования. Идея Матрешки проста: с вебом всё в порядке. Вся логика, которую пишет программист, находится, как и должна, в JavaScript файлах, а HTML остаётся языком разметки гипертекста. Шутка об HTML программисте должна остаться шуткой.
2. Минимум сущностей
Матрешка не требует создания избыточных сущностей. Благодаря простому синтаксису привязок, связь между JavaScript и HTML может быть описана там же, где и логика. Программисту не требуется задумываться сразу о нескольких вещах, размышляя о балансе полномочий объектов. Вопрос где прописать обработчик: во “вьюхе” или в контроллере отпадает сам по себе. Хотя, никто не запрещает разделить данные и контроллер, разместив их в разных JS файлах.
3. Работай с данными, забудь о представлении
Попробовав популярный (но уступающий под натиском более современных продуктов) фреймворк Backbone, сталкиваешься с серьезным неудобством: объявляя данные, зависящие от UI и UI, зависящий от данных, вам, как правило, требуется создать два обработчика события. Один ловит изменения данных, второй ловит пользовательские действия. Проблема подкрепляется еще тем, что HTML элементы, как правило, совершенно идентичны в рамках приложения:
input, select, кастомные виджеты из jQuery UI могут многократно встречаться на странице. Программисту, который реализует еще одну “единицу” приложения (например, форму), приходится пользоваться “копипастой”.С Матрешкой всё намного проще. Вам нужно лишь однажды объявить привязку (в одном месте, а не в двух), затем работать с данными (как с обычными JavaScript объектами), забыв, что у нас вообще есть представление.
4. Гибкость
Новичку часто непонятно, как перейти на новую архитектуру. Порой, для того, чтоб добавить сторонний виджет, нужно приложить немало усилий, изучая адаптеры, директивы и т. п…
Задавшись вопросом, как прикрутить тот или иной скрипт (например, какой-нибудь jQuery плагин), верным ответом будет, в том числе, «сделаю как знаю». Вывод какого-нибудь виджета, будь то Google Maps или одна из многочисленных галерей, делается так, как указано в официальной документации к виджету. Матрешка создана с любовью к VanillaJS.
5. Ненавязчивая архитектура
Большинство популярных фреймворков закладывают принципы структурирования кода, ограничивая творчество программиста, как архитектора ПО. Я не считаю, что это очень плохо, хотя часто задаешься вопросом «а почему нужно делать именно так»?..
Матрешка не заставляет использовать определенную структуру кода, и не принуждает пользоваться хорошими, но, возможно, не самыми удачными решениями. Вы сами выбираете паттерны проектирования и структурирования приложения. Хоть Матрешка и позиционируется, как фреймворк, но, скорее, это библиотека, уменьшающая объем предстоящей работы.
6. Меньше кода
Самая главная задача, которая ставилась при разработке фреймворка — решение максимально большого круга задач (в разумных пределах). Поэтому, результирующий код, как правило, выглядит достаточно компактно, особенно прибегая к помощи ECMAScript 6.
7. Легко понять, что происходит
Из-за ненавязчивости рекомендаций и отсутствии жесткого регламентирования любой, кто не знаком с фреймворком, но хорошо знает JavaScript, скорее всего, разберется в вашем коде (если вы, конечно, сами хороший программист :). При создании методов, одним из важных приоритетов была очевидность их функциональности.
8. Легко начать
Для того, чтоб начать работать с Матрешкой, нужно всего лишь знать назначение трех классов и нескольких методов. Остальное — синтаксических сахар. В документации они помечены красным флажком, чтоб было легче ориентироваться.
9. Небольшой размер
Матрешка достаточно компактна для фреймворка. На момент написания статьи Матрешка весит меньше 38K/12K зазиповано.
10. Поддержка синтаксиса ECMAScript 6
Поддержка JavaScript следующего поколения является одной из самых приоритетных задач. На сегодняшний день, Матрешка, кроме основных возможностей ECMAScript 6, поддерживает классы и циклы
for..of. В дальнейшем, при развитии языка, новые возможности будут добавляться в первую очередь.11. Документация (бонусная причина)
Все знают, что программист обязан знать английский язык, так как большинство актуальных материалов и статей, в первую очередь, выходят на английском. Но я уверен, что большинство людей, читающих эту статью, несмотря на свои знания английского (от посредственных до отличных), отдадут предпочтение русскоязычным материалам.
Документация, начиная с этого года будет выходить на двух языках: на русском и английском. Причем, обе версии, являясь официальными версиями, будут всегда оставаться актуальными.
Вот такой краткий пост получился. Всем пятницы!
Комментарии (36)
jMas
10.04.2015 08:10+1В документации Матрешки много примеров, где JS обработчики прибивается
гвоздями(или данные биндятся) селекторами к HTML разметке.
В ангуляре, например, директивы как раз выполняют роль клея между логикой контроллера и представлением.
Простой пример: в проекте решили убрать часть представления — убрали вывод имени пользователя.
В ангуляре: убрать часть HTML кода для вывода имени пользователя. Матрешка: убрать часть HTML кода для вывода имени пользователя, почистить логику, где биндится имя пользователя из данных к HTML селектору.
Или в Матрешке не так? Пожалуйста, поправьте.
shasoft
10.04.2015 08:40Так ведь все-равно логика в ангуляре в js коде и её придется убирать. Т.е. все что убирается в ангуляре — это только привязка. А как правило одной привязкой дело не ограничивается.
jMas
10.04.2015 08:51Не всегда необходимо заниматься чисткой логики в ангуляре.
Пример: массив объектов, у каждого объекта есть свойство «user». Этот массив попадает в код клиентского приложения через аякс-запрос, кладется в скоуп контроллера, через скоуп попадает во вью, где происходит перебор элементов и вывод списка этих записей. Мне достаточно убрать «user» в коде серверного приложения и из HTML разметки представления.shasoft
10.04.2015 09:00-1А убрать ajax запрос не нужно? ;)
Ведь все равно это значение как-то попадает в scope перед тем как его выводят.jMas
10.04.2015 09:12+1Аякс запрос трогать не нужно — запросом мы получаем список записей, у каждой записи было проставлено свойство «user», которое хранило информацию о пользователе. Свойство «user» (для каждой записи) убрали на серверной стороне — на клиентской убрали HTML разметку, отвечающую за вывод пользователя для каждой записи. Логику JavaScript контроллера не трогали.
Finom Автор
10.04.2015 09:03-1Именно так. Но проблема с «убиранием» части логики мне кажется надуманной.
tenbits
10.04.2015 12:15+2app.bindNode( 'x', '.my-input' );
Ладно «убирание», но ведь таким образом мы ставим контроллер в зависимость от шаблона. Здесь программист должен заранее подумать какой селектор потом будет или уже есть в шаблоне. Как минимум, лучше объявить соглашение: Связь «свойство-елемент» создается через селектор, например, ".bind-NAME". Тогда можно будет и «автоматом» связывать шаблон и модель, как это обычно делается, а на случай экзотического поведения уже вручную связывать некоторые свойства с элементами по селектору. Скажем такое поведение уже на порядок лучше:
<input type="text" class="bind-foo"> <script> var app = new Matreshka({ foo : null }); app.foo = 'Двустороннее связывание данных в JS? Серьезно?'; </script>shasoft
10.04.2015 15:40Весьма полезное было бы дополнение — такая вот автопривязка. В этом случае не нужно писать ".my-input" в html и в js, достаточно в одном месте.
Finom Автор
10.04.2015 17:35Шаблонизатора в ближайшем времени точно не будет.
Я делал два проекта, в которых используется такая логика (требование клиента). В итоге, получился совершенно другой фреймворк, заточенный под узкую задачу проекта.tenbits
10.04.2015 17:47+3А при чём здесь шаблонизатор? Я говорю о более чистом разделение ответственности, ведь иначе пример из главной похож больше не на «JavaScript фреймворк для программистов», а на «JavaScript фреймворк для верстальщиков». Никаким образом нельзя смешивать селекторы для стилизации и селекторы для связывания. И последние должны также выделяться префиксом для явности.
eld0727
10.04.2015 08:11По 3-ему пункту, как я понял это сделано при помощи Object.observe, то есть мы имеем ситуация что приложение не будет работать в «немного более старых браузерах чем хотелось бы». Или тут есть dirty check как в angular.js (про производительность которого вообще стоит молчать)?
Итого: мне кажется современный мир пока не может ничего лучше предложить, чем двойное связывание через событияFinom Автор
10.04.2015 08:59+1Тут используются акцессоры, добавленные с помощью Object.defineProperty. А эта функция работает везде, включая ИЕ8. dirty check — это очень плохая идея.
lega
10.04.2015 23:29Или тут есть dirty check как в angular.js (про производительность которого вообще стоит молчать)?
А чего молчать, один из самых быстрых фреймворков, гораздо быстрее чем knockout.js который основан на observable подходе, в матрешке принцип тот же, но поверх Object.defineProperty.
Кстати не знаете какие фреймворки уже используют Object.observe (не считая Angular Light и Angular 2, кстати в последний вроде ещё не «вкрутили»)?
bushart
10.04.2015 13:11+4Андрей, вы занимаетесь продвижение фреймворка за рубежом?
Я спрашиваю потому, что кроме функциональности фреймворка многих интересует его популярность. Если мы делаем свои стартапы, то можем делать, что хотим, но если мы работаем на аутсорсе, мы должны быть уверенны, что делаем качественный продукт. Один из критериев качества, я считаю, является возможность легко передать разработку проекта другой команде. Так вот, какие риски столкнуться с тем, что заказчик не найдет специлистов, знабщих этот фреймворк за приделами бывшего СНГ?Finom Автор
10.04.2015 18:09Понимаю вас… Документация пишется на двух языках, это сделано как раз для разработчиков из-за бугра. Будет опубликовано несколько статей англоязычных ресурсах. Европа и США — очень важные приоритеты проекта. Но буду откровенен, полноценного продвижения, на сегодняшний день, нет.
С другой стороны, Матрешка — библиотека основанная на прототипном наследовании, с которым должен быть знаком любой JS разработчик. Единственное, что действительно нужно знать — это то, как связывать свойства и ноды (метод bindNode, средняя сложность), как ловить изменения данных (метод on, который очень похож на одноименный метод из Backbone, малая сложность) и как рендерить коллекции (сложность выше среднего). Остальное не настолько важно. Здесь нет каких-нибудь специфичных концепций, модных аббревиатур и разглагольствований, так что программисту, никогда не имевшему дела с Матрешкой, не должно составить большого труда разобраться с основами.
rboots
10.04.2015 15:56-2Второй и пятый пункты очень понравились, загорелся пробовать.
По популярности фреймворка важный пункт. Работодатель знает Ангуляр, Бекбон, а я приду и скажу, что предпочитаю Матрёшку. Как-то не хочется их этим шокировать.
И название лучше сменить, мы же не видим у американцев фреймворки «Дядя Сэм» или «Звёздно-полосатый фреймворк», потому что они не выстрелят. Для иностранного потребителя матрёшка это длинно и непонятно, а для российского — отдаёт квасным патриотизмом и ассоциируется с детской игрушкой. Именно с квасным, вообще я за патриотизм, не подумайте.
Большой респект вам за начинание, очень правильные идеи положены в основу. Хочется верить, что всё у вас с этим фреймворком будет хорошо.shasoft
10.04.2015 16:22+1>>вообще я за патриотизм
Вы предпочитаете какое название
1) Балалайка
2) Ушанка
3) Водка?
:)
А по сути — название матрешка как раз подходит: фреймворк — это как самая маленькая матрешка, и каждый делают свою настройку — вполне всё логично. Да и на западе вроде этот бренд раскручен и многие должны знать суть матрешки.
Finom Автор
10.04.2015 18:17Просто название очень хорошо подходит для фреймворка, умеющего наследование. Балалайка — это, скорее, шуточное название, взятое, как логическое продолжение названия фреймворка. Vodkajs, к сожалению, было уже занято :)
З. Ы. Матрешка — японская игрушка, с немного измененным дизайном.
StreetStrider
10.04.2015 22:45Матрешка не заставляет использовать определенную структуру кода, и не принуждает пользоваться хорошими, но, возможно, не самыми удачными решениями. Вы сами выбираете паттерны проектирования и структурирования приложения. Хоть Матрешка и позиционируется, как фреймворк, но, скорее, это библиотека, уменьшающая объем предстоящей работы.
Это мудро и честно. Хотя и требует большей дисциплины.
shasoft
15.04.2015 09:16Неплохо было бы сделать пример одностраничного приложения с несколькими страницами. А-ля angular
Finom Автор
15.04.2015 09:56Киньте пример. Документация к Матрешке и есть одностраничное приложение с несколькими страницами (пока без рефакторинга).
shasoft
15.04.2015 15:58Точно, документация к матрешке — как раз именно то, что я имел ввиду.
Но неплохо бы расписать как вообще самому такое написать. В частности у вас создается класс Matreshka — как его вставить в одностраничное приложение? Т.е. к примеру создал я класс матрешки, сделал bindNode переменной к DOM элементу (к примеру к полю input ввода логина) на странице 1. Потом dom с этим input-ом удалил со страницы (загрузилась новая страница 2, которая переформировала DOM). В этом случае класс матрешки нужно пересоздавать или уже созданный подойдет?
p.s.надеюсь мои вопросы не слишком делитанскиеFinom Автор
16.04.2015 10:37Нет, хорошие вопросы. Документация сделана нетрадиционным способом, так как HTML сгенерирован заранее (для поисковых систем, производительности и работы оффлайн). Это не «общий» случай использования Матрешки. Я активно думаю над тем, как еще расширить примеры к Матрешке новыми примерами.
… Потом dom с этим input-ом удалил со страницы (загрузилась новая страница 2, которая переформировала ...
Тут два варианта:
1. Иметь один объект. Убирать старые байндинги, добавлять новые, когда DOM дерево меняется.
2. Иметь несколько объектов и за каждым закрепить своё дерево DOM. Этот вариант проще в реализации, он не требует уничтожения байндингов.
Сбросьте какой-нибудь пример, реализованный на базе другого фреймворка, я смотгу ответить конкретнее.shasoft
16.04.2015 14:04С примером проблема — я на angular сейчас делаю, а там работа с одностраничными сайтами уже встроена в сам фреймворк: там и роутинг, и подгрузка.
Однако насколько я понимаю, там используется вариант 2. Т.е. есть область видимости (экземпляр класса матрешка) и она своя для каждой подгружаемой страницы + есть глобальная область + создаются свои локальные области видимости для каждого компонента (если нужно). Только вот как именно там биндин реализован — не очень понимаю. Для меня сайтописательство — это хобби, а о\не основное занятие. Собственно поэтому мне и желателен интсрумент которым можно пользоваться, не влезая в дебри понимания. Поэтому и пример нужен.
Наверное стоит придумать синитический пример с несколькими страницами.Finom Автор
16.04.2015 14:21Такой пример совершенно не подходит для демонстрации возможностей Матрешки. Так что давайте вы попробуете, а я отвечу на вопросы, если у вас возникнут проблемы.
Я уже писал раньше (в первых статьях о Матрешке), что для простых сайтов (не приложений или приложений, но с минимальным функционалом) лучше использовать Ангуляр. Это лучшее решение для небольших прототипов и малофункциональных приложений.
k12th
3) Так можно напугать только тех, кто не знает Backbone (и десятки плагинов на любой вкус для связывания данных).
4) «сделаю, как знаю» — это, как правило «кое-как че-то притулил сбоку», см. пункты 5 и 7.
5) и 7) Тут недавно обсуждали, чем хороши и чем плохи фреймворки. Вот jQuery, например, тоже не накладывает ограничений, и теперь «джейквери» — это синоним «спагетти».
11)
У вас код прибегает к помощи ES6? «Не пиши меня, страшный программист, я ES6 на помощь позову!»
Finom Автор
Уверен, что костыли найдутся для любого неудачного решения.
Тут всё зависит от того, насколько вы хороший программист. Вся соль в том, что вам не требуется идти на StackOverflow или на Тостер за ответом на вопрос, как прикрутить скрипт X к фреймворку Y. Матрешка по умолчанию работает со всеми возможными библиотеками (за исключением каких-нибудь хитрых решений, о которых я пока не знаю). Но это не новость, тот же Backbone умеет это делать.
Я не совсем понял этот пункт. Во-первых jQuery — не фреймворк. Во-вторых, не понимаю, почему она (библиотека) у вас ассоциируется со спагетти.
k12th
Ну вот о чем и речь. В более жестком окружении (читай: во фреймворке) плохой программист будет ограничен в своих возможностях наговнякать спагетти-кода. А хороший программист и так не заблудится, кто же спорит.
Изобретать архитектуру, конечно, интересно. Но иногда нужно просто быстро сделать прототип и не думать, как его изящнее организовать.
Ну да, все контрибьюторы в Backbone — дураки, а вы один Д'Артаньян в белом.
Матрешка — тоже не фреймворк (как и Backbone).
Полтора года назад в Москве была конфа по jQuery, в конце была Q&A сессия с разработчиками. Приз за лучший вопрос получил парень, который спросил, почему код на jQuery «такие макароны».
Я честно не понимаю, почему она у вас не ассоциируется со спагетти-кодом.
Finom Автор
У нас совершенно разные взгляды на программирование в принципе. Мне с института не нравились жесткие обязательства по структуре кода.
Я нигде не говорил, что кто-то дурак.
Это очень слабый аргумент.
Я много лет использовал jQuery (хотя сейчас в нем нет никакой нужды) и не встречал макарон, вызванных не криворукостью разработчика, а проблемами в библиотеке. Я не защищаю jQuery, просто пытаюсь понять, что вы мне хотите сказать в контексте Матрешки.
k12th
Не поймите меня превратно, мне нравится идея простой библиотеки для связывания. Меня смущают ваши аргументы.
Даже, может быть, я попробую сделать что-то на Матрешке (+ Backbone:)).