Обзор JS-фреймворков. Путешествие через джунгли JavaScript MVC. Ч. 1

[@romy4]

Объявлена неделя Javascript на хабре, количество постов и опыта увеличивается вдвое :)

[@Mushtat]

И за кадром звук из героев III, означающий новую неделю )

[@So1]

Популяция Javascript-кодеров увеличивается вдвое ;-)

[@Makito]

посмотрел в код примера на jquery и ощутил себя лузером…

[@pro100tak]

А что там сложного?

[@vermilion1]

Скорей всего имеется ввиду организация кода — все на своем месте, оптимизировано обращение к селекторам и т.д.

[@Makito]

сложного ничего, но сама структурированность и построение кода… Если вы так пишите — очень вам завидую :)

[@return]

на самом деле подход не сказать чтобы очень клевый, так писать не стоит

[@Makito]

поделитесь методиками как лучше, буду благодарен :)

[@return]

Сам не знаю как истинно верно :)
Но выносить абсолютно все в разные методы ненужного объекта без какой-нибудь необходимости не стоит точно.

[@pro100tak]

Отчего же не стоит? Код структурирован, объект содержит необходимые поля и методы. Тут ещё дело вот в чём — самого кода на полторы сотни строк — кот наплакал. Даже стыдно сделать тяп-ляп. Да и не получится — весь код не просто в память (человеческую) помещается, но и даже на 2 экрана.

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

[@return]

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

Все это дело можно написать гораздо «более лучше» при сохранении компактности.

[@pro100tak]

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

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

[@return]

Вы такой странный, даже код мой не видели, а уже все про него знаете ;)
Мой путь — красивый код.

Закончим на этом бесполезную дискуссию.

[@pro100tak]

Без проблем!

[@Dark_Knight]

Спасибо за статью, как раз собирался взяться изучать javascript-фреймворк, а тут вы в помощь! Спасибо

[@Athari]

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

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

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

Пойду погляжу примеры из Labs…

[@Makito]

Мне кажется, что на примере такого простого приложения, использование данных фреймворков действительно выглядит как стрельба из пушки по воробьям, но если воспринимать в контексте большого приложения, то затраты на писанину окупятся легкостью доработки и ведения проекта.

[@Athari]

Я могу понять нагромождение классов и прочие особенности сложных приложений, но всё-таки простые вещи в сложных фреймворках должны делаться просто, безо всяких переподвыподвертов, хаков и кучи инфраструктурного кода. Например, вот код из 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).

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

Я ещё молчу про фреймворки, где под каждый элемент управления (кнопка, строчка таблицы и т.п.) пишется отдельный класс.

[@Istergul]

А кто подскажет, как backbone заставить работать только с POST/GET запросами к серверу?

[@avrelian]

Backbone.emulateHTTP

[@Istergul]

Благодарю :)

[@morr]

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

И если учитывать этот критерий, то очень многие mvc фреймворки можно сразу отбрасывать, в первую очередь, пожалуй, большинство имеющих data-binding.