Comments 23
Объявлена неделя Javascript на хабре, количество постов и опыта увеличивается вдвое :)
+4
посмотрел в код примера на jquery и ощутил себя лузером…
0
А что там сложного?
0
Скорей всего имеется ввиду организация кода — все на своем месте, оптимизировано обращение к селекторам и т.д.
0
сложного ничего, но сама структурированность и построение кода… Если вы так пишите — очень вам завидую :)
0
на самом деле подход не сказать чтобы очень клевый, так писать не стоит
0
поделитесь методиками как лучше, буду благодарен :)
0
Сам не знаю как истинно верно :)
Но выносить абсолютно все в разные методы ненужного объекта без какой-нибудь необходимости не стоит точно.
Но выносить абсолютно все в разные методы ненужного объекта без какой-нибудь необходимости не стоит точно.
0
Отчего же не стоит? Код структурирован, объект содержит необходимые поля и методы. Тут ещё дело вот в чём — самого кода на полторы сотни строк — кот наплакал. Даже стыдно сделать тяп-ляп. Да и не получится — весь код не просто в память (человеческую) помещается, но и даже на 2 экрана.
Вот тут внутри организовано всё точно также, только немного сложнее структура + используются конструкторы и т.д.
Вот тут внутри организовано всё точно также, только немного сложнее структура + используются конструкторы и т.д.
0
Не стоит потому что объект не нужен. Создавать объект только ради того, чтобы дернуть у него метод init — это рак мозга.
Еще больший рак мозга, к примеру, метод объекта blurOnEnter, который нужен как обработчик собырия keypress в одном из полей. Это просто мешанина ненужных методов, которые никак не связаны с объектом. Можно сказать что это не просто полезный объект, а неймспейс с кучей мусорных функций.
Все это дело можно написать гораздо «более лучше» при сохранении компактности.
Еще больший рак мозга, к примеру, метод объекта blurOnEnter, который нужен как обработчик собырия keypress в одном из полей. Это просто мешанина ненужных методов, которые никак не связаны с объектом. Можно сказать что это не просто полезный объект, а неймспейс с кучей мусорных функций.
Все это дело можно написать гораздо «более лучше» при сохранении компактности.
+2
> Все это дело можно написать гораздо «более лучше» при сохранении компактности.
Ммм? Написать можно кучей разных способов, никто не спорит. Однако — неужели Вы спорите о необходимости группировать методы для работы с сущностями в объекты/коллекции и т.д.? Либо Ваш путь — спагетти с навешиванием обработчиков обычной простынёй кода?
> Создавать объект только ради того, чтобы дернуть у него метод init — это рак мозга.
Рак мозга — не посмотреть что метод init() это просто точка входа, которая инициализирует переменные, развесит обработчики и спокойно завершится. А вот обработчики — методы данного объекта (что какбе логично) — просто функции, которые у Вас лежали бы в многострадальном window захламляя его.
Ммм? Написать можно кучей разных способов, никто не спорит. Однако — неужели Вы спорите о необходимости группировать методы для работы с сущностями в объекты/коллекции и т.д.? Либо Ваш путь — спагетти с навешиванием обработчиков обычной простынёй кода?
> Создавать объект только ради того, чтобы дернуть у него метод init — это рак мозга.
Рак мозга — не посмотреть что метод init() это просто точка входа, которая инициализирует переменные, развесит обработчики и спокойно завершится. А вот обработчики — методы данного объекта (что какбе логично) — просто функции, которые у Вас лежали бы в многострадальном window захламляя его.
+1
Спасибо за статью, как раз собирался взяться изучать javascript-фреймворк, а тут вы в помощь! Спасибо
0
Поглядел код на всех этих фреймворках (кроме кофе и джавы — их поверхностно). Полного оху… офигения и вылезания глаз из орбит не вызвал только код KnockoutJS и «голый» на jQuery. Все остальные тако-о-ой лес городят, что страшно становится. Когда вместо однострочного if навешивается гора байндингов, фильтров и прочего — хочется выть.
Вы какую ставили цель: показать красоту фреймворка (то есть выразительность, краткость, читаемость) или его мощь (то есть использовать в коде максимум предоставляемых возможностей)?
На самом сайте не хватает перекрёстных ссылок: на страничке примера хорошо бы давать ссылку на код, а во все папки с кодом положить readme, где первая ссылка — на рабочий пример. Ходить параллельно не очень удобно.
Пойду погляжу примеры из Labs…
Вы какую ставили цель: показать красоту фреймворка (то есть выразительность, краткость, читаемость) или его мощь (то есть использовать в коде максимум предоставляемых возможностей)?
На самом сайте не хватает перекрёстных ссылок: на страничке примера хорошо бы давать ссылку на код, а во все папки с кодом положить readme, где первая ссылка — на рабочий пример. Ходить параллельно не очень удобно.
Пойду погляжу примеры из Labs…
+2
Мне кажется, что на примере такого простого приложения, использование данных фреймворков действительно выглядит как стрельба из пушки по воробьям, но если воспринимать в контексте большого приложения, то затраты на писанину окупятся легкостью доработки и ведения проекта.
0
Я могу понять нагромождение классов и прочие особенности сложных приложений, но всё-таки простые вещи в сложных фреймворках должны делаться просто, безо всяких переподвыподвертов, хаков и кучи инфраструктурного кода. Например, вот код из Dojo:
Это — код модели. В «голом» jQuery мы не даём ввести пустой элемент (if (!$.trim($input.val())) return), здесь пишем вручную какой-то маловменяемый процедурный (ни разу не декларативный!) фильтр и прикручиваем его какой-то трёхуровневой конструкцией с байндингами. В «голом» jQuery мы проходимся по коллекции и считаем количество, здесь делаем то же самое, но с байндингами, хитрым чтением свойств и проверками, что элемент — это элемент (return item && !item.completed.value).
Как, ну как такая библиотека может упростить жизнь? Если для такого простого примера приходится городить всю эту хрень, то что будет со сложными объектами? И всё это ещё чёрта с два отладишь нормально. И про автодополнение кода из-за всех этих строчек можно забыть.
Я ещё молчу про фреймворки, где под каждый элемент управления (кнопка, строчка таблицы и т.п.) пишется отдельный класс.
define(["dojo/_base/declare", "dojox/mvc/StatefulModel", "todo/store/LocalStorage", "dojox/mvc", "dojo/_base/lang", "dojo/_base/array"],
function(declare, StatefulModel, LocalStorage, mvc, lang, array) {
return declare([StatefulModel], {
data: {
id: "todos-dojo",
todos : [],
incomplete: 0,
complete: 0
},
store: new LocalStorage(),
constructor: function () {
var data = this.store.get(this.data.id) || this.data;
this._createModel(data);
this.setUpModelBinding();
this.updateTotalItemsLeft();
},
setUpModelBinding: function () {
mvc.bind(this.incomplete, "value", this.complete, "value", lang.hitch(this, function (value) {
return this.todos.get("length") - value;
}));
array.forEach(this.todos, lang.hitch(this, "bindItemProps"));
this.todos.watch(lang.hitch(this, "onTodosModelChange"));
},
bindItemProps: function (item) {
mvc.bindInputs([item.completed], lang.hitch(this, "updateTotalItemsLeft"));
mvc.bindInputs([item.title], lang.hitch(window, setTimeout, lang.hitch(this, "deleteEmptyTasks")));
},
deleteEmptyTasks: function () {
var len = this.todos.length, idx = 0;
while (idx < len) {
if (!this.todos[idx].title.value.length) {
this.todos.remove(idx);
len--;
continue;
}
idx++;
}
},
onTodosModelChange: function (prop, oldValue, newValue) {
this.updateTotalItemsLeft();
if (typeof prop === "number" && !oldValue && newValue) {
this.bindItemProps(newValue);
}
},
updateTotalItemsLeft: function () {
this.incomplete.set("value", array.filter(this.todos, function (item) {
return item && !item.completed.value;
}).length);
}
});
});
Это — код модели. В «голом» jQuery мы не даём ввести пустой элемент (if (!$.trim($input.val())) return), здесь пишем вручную какой-то маловменяемый процедурный (ни разу не декларативный!) фильтр и прикручиваем его какой-то трёхуровневой конструкцией с байндингами. В «голом» jQuery мы проходимся по коллекции и считаем количество, здесь делаем то же самое, но с байндингами, хитрым чтением свойств и проверками, что элемент — это элемент (return item && !item.completed.value).
Как, ну как такая библиотека может упростить жизнь? Если для такого простого примера приходится городить всю эту хрень, то что будет со сложными объектами? И всё это ещё чёрта с два отладишь нормально. И про автодополнение кода из-за всех этих строчек можно забыть.
Я ещё молчу про фреймворки, где под каждый элемент управления (кнопка, строчка таблицы и т.п.) пишется отдельный класс.
+1
А кто подскажет, как backbone заставить работать только с POST/GET запросами к серверу?
0
> Предложенные нами критерии выбора фреймворка
Есть ещё один критерий, про который большинство почему-то или забывают, или игнорируют.
А именно возможность «контроллерам» фреймворка использовать в качестве view не только собственные шаблоны, но и уже отрендеренный html код.
Во-первых, это необходимо для seo, когда контент страниц должен быть доступен поисковикам. На клиент-сайд MVC архитектуре ведь можно строить не только интерфейсы различных сервисов, которым индексация ни к чему, но и всё остальное разннообразие веб сайтов.
Во-вторых, это может понадобиться для большого объёма данных, когда рендеринг всего на яваскрипте оказывается слишком медленым. Тут пожалуй, наиболее простой пример — это отображение десятков-сотни-другой комментариев к чему-либо.
И если учитывать этот критерий, то очень многие mvc фреймворки можно сразу отбрасывать, в первую очередь, пожалуй, большинство имеющих data-binding.
Есть ещё один критерий, про который большинство почему-то или забывают, или игнорируют.
А именно возможность «контроллерам» фреймворка использовать в качестве view не только собственные шаблоны, но и уже отрендеренный html код.
Во-первых, это необходимо для seo, когда контент страниц должен быть доступен поисковикам. На клиент-сайд MVC архитектуре ведь можно строить не только интерфейсы различных сервисов, которым индексация ни к чему, но и всё остальное разннообразие веб сайтов.
Во-вторых, это может понадобиться для большого объёма данных, когда рендеринг всего на яваскрипте оказывается слишком медленым. Тут пожалуй, наиболее простой пример — это отображение десятков-сотни-другой комментариев к чему-либо.
И если учитывать этот критерий, то очень многие mvc фреймворки можно сразу отбрасывать, в первую очередь, пожалуй, большинство имеющих data-binding.
0
Sign up to leave a comment.
Обзор JS-фреймворков. Путешествие через джунгли JavaScript MVC. Ч. 1