Pull to refresh

Comments 23

Объявлена неделя Javascript на хабре, количество постов и опыта увеличивается вдвое :)
И за кадром звук из героев III, означающий новую неделю )
Популяция Javascript-кодеров увеличивается вдвое ;-)
посмотрел в код примера на jquery и ощутил себя лузером…
Скорей всего имеется ввиду организация кода — все на своем месте, оптимизировано обращение к селекторам и т.д.
сложного ничего, но сама структурированность и построение кода… Если вы так пишите — очень вам завидую :)
на самом деле подход не сказать чтобы очень клевый, так писать не стоит
поделитесь методиками как лучше, буду благодарен :)
Сам не знаю как истинно верно :)
Но выносить абсолютно все в разные методы ненужного объекта без какой-нибудь необходимости не стоит точно.
Отчего же не стоит? Код структурирован, объект содержит необходимые поля и методы. Тут ещё дело вот в чём — самого кода на полторы сотни строк — кот наплакал. Даже стыдно сделать тяп-ляп. Да и не получится — весь код не просто в память (человеческую) помещается, но и даже на 2 экрана.

Вот тут внутри организовано всё точно также, только немного сложнее структура + используются конструкторы и т.д.

Не стоит потому что объект не нужен. Создавать объект только ради того, чтобы дернуть у него метод init — это рак мозга.
Еще больший рак мозга, к примеру, метод объекта blurOnEnter, который нужен как обработчик собырия keypress в одном из полей. Это просто мешанина ненужных методов, которые никак не связаны с объектом. Можно сказать что это не просто полезный объект, а неймспейс с кучей мусорных функций.

Все это дело можно написать гораздо «более лучше» при сохранении компактности.
> Все это дело можно написать гораздо «более лучше» при сохранении компактности.
Ммм? Написать можно кучей разных способов, никто не спорит. Однако — неужели Вы спорите о необходимости группировать методы для работы с сущностями в объекты/коллекции и т.д.? Либо Ваш путь — спагетти с навешиванием обработчиков обычной простынёй кода?

> Создавать объект только ради того, чтобы дернуть у него метод init — это рак мозга.
Рак мозга — не посмотреть что метод init() это просто точка входа, которая инициализирует переменные, развесит обработчики и спокойно завершится. А вот обработчики — методы данного объекта (что какбе логично) — просто функции, которые у Вас лежали бы в многострадальном window захламляя его.
Вы такой странный, даже код мой не видели, а уже все про него знаете ;)
Мой путь — красивый код.

Закончим на этом бесполезную дискуссию.
Спасибо за статью, как раз собирался взяться изучать javascript-фреймворк, а тут вы в помощь! Спасибо
Поглядел код на всех этих фреймворках (кроме кофе и джавы — их поверхностно). Полного оху… офигения и вылезания глаз из орбит не вызвал только код KnockoutJS и «голый» на jQuery. Все остальные тако-о-ой лес городят, что страшно становится. Когда вместо однострочного if навешивается гора байндингов, фильтров и прочего — хочется выть.

Вы какую ставили цель: показать красоту фреймворка (то есть выразительность, краткость, читаемость) или его мощь (то есть использовать в коде максимум предоставляемых возможностей)?

На самом сайте не хватает перекрёстных ссылок: на страничке примера хорошо бы давать ссылку на код, а во все папки с кодом положить readme, где первая ссылка — на рабочий пример. Ходить параллельно не очень удобно.

Пойду погляжу примеры из Labs…
Мне кажется, что на примере такого простого приложения, использование данных фреймворков действительно выглядит как стрельба из пушки по воробьям, но если воспринимать в контексте большого приложения, то затраты на писанину окупятся легкостью доработки и ведения проекта.
Я могу понять нагромождение классов и прочие особенности сложных приложений, но всё-таки простые вещи в сложных фреймворках должны делаться просто, безо всяких переподвыподвертов, хаков и кучи инфраструктурного кода. Например, вот код из Dojo:

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).

Как, ну как такая библиотека может упростить жизнь? Если для такого простого примера приходится городить всю эту хрень, то что будет со сложными объектами? И всё это ещё чёрта с два отладишь нормально. И про автодополнение кода из-за всех этих строчек можно забыть.

Я ещё молчу про фреймворки, где под каждый элемент управления (кнопка, строчка таблицы и т.п.) пишется отдельный класс.
А кто подскажет, как backbone заставить работать только с POST/GET запросами к серверу?
> Предложенные нами критерии выбора фреймворка
Есть ещё один критерий, про который большинство почему-то или забывают, или игнорируют.
А именно возможность «контроллерам» фреймворка использовать в качестве view не только собственные шаблоны, но и уже отрендеренный html код.
Во-первых, это необходимо для seo, когда контент страниц должен быть доступен поисковикам. На клиент-сайд MVC архитектуре ведь можно строить не только интерфейсы различных сервисов, которым индексация ни к чему, но и всё остальное разннообразие веб сайтов.
Во-вторых, это может понадобиться для большого объёма данных, когда рендеринг всего на яваскрипте оказывается слишком медленым. Тут пожалуй, наиболее простой пример — это отображение десятков-сотни-другой комментариев к чему-либо.

И если учитывать этот критерий, то очень многие mvc фреймворки можно сразу отбрасывать, в первую очередь, пожалуй, большинство имеющих data-binding.
Only those users with full accounts are able to leave comments. Log in, please.