Комментарии 7
Пожелание: избавиться от зависимости jQuery.
+1
Уже добавил в план.
+1
Тут, конечно, палка о двух концах. Если переписать таким образом библиотеку, то, скорее всего, ее размер вырастет. Для сайтов/приложений где все равно используется jQuery (а их большинство) это даст только бесполезное увеличение объема. Но с другой стороны, конечно, позволит не подключать увесистую библиотеку там, где это не требуется.
Оптимальным было бы сделать некую jqLite (как в Angular, кажется), где реализовать только ту часть функционала, которая используется матрешкой. Тогда ее можно было бы использовать в тех приложениях, где нет необходимости во всей jQuery и дало бы экономию по объему кода. Но это требует больше усилий автора на разработку, а он мог бы потратить их на улучшения непосредственно самой матрешки.
С третьей стороны, сейчас на сайте jQuery можно самому собрать лайт-версию. Возможно, это самый компромиссный вариант. Только тогда автору в документации надо указать, что конкретно используется.
Оптимальным было бы сделать некую jqLite (как в Angular, кажется), где реализовать только ту часть функционала, которая используется матрешкой. Тогда ее можно было бы использовать в тех приложениях, где нет необходимости во всей jQuery и дало бы экономию по объему кода. Но это требует больше усилий автора на разработку, а он мог бы потратить их на улучшения непосредственно самой матрешки.
С третьей стороны, сейчас на сайте jQuery можно самому собрать лайт-версию. Возможно, это самый компромиссный вариант. Только тогда автору в документации надо указать, что конкретно используется.
+1
Насколько я понял, данная библиотека является вариацией на тему data binging. Вопрос у меня возник такой: если библиотека для работы с данными, тогда зачем зависимость от утилиты предназначенной преимущественно для работы с DOM?
Пример: проект на Sencha Touch / Ext.Js либо на любом другом фреймверке, где уже есть поддержка утилитарной библиотеки для работы с DOM, наличие еще одной утилитарной библиотеки для работы с DOM не допустимо. Другая ситуация: серверный JS — как быть, если хочешь использовать бибилиотеку, где наличие jQuery будет выглядеть странно?
Вот почему хотелось бы, чтобы библиотека выполняла исключительно функцию датабиндинга, а работа с элементами DOM была вынесена как, например, плагин.
Пример: проект на Sencha Touch / Ext.Js либо на любом другом фреймверке, где уже есть поддержка утилитарной библиотеки для работы с DOM, наличие еще одной утилитарной библиотеки для работы с DOM не допустимо. Другая ситуация: серверный JS — как быть, если хочешь использовать бибилиотеку, где наличие jQuery будет выглядеть странно?
Вот почему хотелось бы, чтобы библиотека выполняла исключительно функцию датабиндинга, а работа с элементами DOM была вынесена как, например, плагин.
0
Очень заинтересовала Ваша библиотека.
Метод set полезная штука, но есть варианты, когда имена внутри класса не совпадают с именами пришедшими с сервера. Чтобы избежать рассуждений из серии: «нужно делать единообразие имен на клиенте и сервере» рассмотрим пример, когда одно приложение работает с API разных систем.
Из выше сказанного возникает вопрос, планируется ли реализация mapping'а?
Было бы очень удобно.
PS Спасибо за библиотеку, надеюсь удастся её эффективно применить в проекте.
Кстати, что с лицензией на использование?
Метод set полезная штука, но есть варианты, когда имена внутри класса не совпадают с именами пришедшими с сервера. Чтобы избежать рассуждений из серии: «нужно делать единообразие имен на клиенте и сервере» рассмотрим пример, когда одно приложение работает с API разных систем.
Из выше сказанного возникает вопрос, планируется ли реализация mapping'а?
Было бы очень удобно.
PS Спасибо за библиотеку, надеюсь удастся её эффективно применить в проекте.
Кстати, что с лицензией на использование?
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
(Архив) Matreshka.js — MK.Object