Pull to refresh

Comments 43

Скролл умер.
А если серьёзно, то код сложно читать с этими плюсами и минусами. Может можно как-то цветом обозначить? И да, спасибо за труд.
Похоже, подсветка кода на Хабре не умеет отображать синтаксис diff. Я к диффам привык, очень информативно, хотя статью пока еще не до конца осилил.
Все же лучше выкладывать итоговый код, без минусов, а дифы прятать в спойлер. А то правда очень тяжело читается.
Очень интересна тема, но из-за плюсов-минусов не смог осилить статью.
Поддерживаю подход и использованием diff. Даже без подсветки это удобнее, чем просто код.
Добавил и перенес в хаб переводы.
А теперь, внимание, главный вопрос: зачем?
Автор как бы намекает
Этот код является более легким в обслуживании, его легче повторно использовать и расширять, и проще тестировать.
Вы действительно считаете, что вот это
Скрытый текст
var Status = Backbone.Model.extend({
    url: '/status'
});

var Statuses = Backbone.Collection.extend({
    model: Status
});

var NewStatusView = Backbone.View.extend({
    events: {
        'submit form': 'addStatus'
    },

    initialize: function() {
        this.collection.on('add', this.clearInput, this);
    },

    addStatus: function(e) {
        e.preventDefault();

        this.collection.create({ text: this.$('textarea').val() });
    },

    clearInput: function() {
        this.$('textarea').val('');
    }
});

var StatusesView = Backbone.View.extend({
    initialize: function() {
        this.collection.on('add', this.appendStatus, this);
    },

    appendStatus: function(status) {
        this.$('ul').append('<li>' + status.escape('text') + '</li>');
    }
});

$(document).ready(function() {
    var statuses = new Statuses();
    new NewStatusView({ el: $('#new-status'), collection: statuses });
    new StatusesView({ el: $('#statuses'), collection: statuses });
});



Легче поддерживать, чем это?
Скрытый текст
$(document).ready(function() {
    $('#new-status form').submit(function(e) {
        e.preventDefault();

        $.ajax({
            url: '/status',
            type: 'POST',
            dataType: 'json',
            data: { text: $('#new-status').find('textarea').val() },
            success: function(data) {
                $('#statuses').append('<li>' + data.text + '</li>');
                $('#new-status').find('textarea').val('');
            }
        });
    });
});




Я вовсе не хочу сказать, что второй пример — элегантный. Но если выбирать наименьшее из двух зол — второй пример намного лучше.
Backbone код легко разносится на файлы где у каждого файла строгие соглашения по именованию и ответственности, а значит на проекте где от фронтенд-кода можно рехнутся будет гораздо проще найти нужный файл и внести правки или создать новую функциональность.

В jQuery же всегда одна и та же проблема — спагетти-код, который, как бы ты не старался будет удерживать рост фронтенда и душить проект.
Вы давно пишете на бэкбоне или чисто теоретизируете? Доводилось ли писать что-то более-менее сложное?
Когда в проекте много разнообразных вьюх, моделей и шаблонов, количество файлов растёт с бешеной скоростью, что, как не трудно догадаться, уже не становится таким очевидным преимуществом.

В jQuery можно написать 3 строчки и они просто будут работать. Без создания новых файлов, вьюх, моделей, коллекций и шаблонов. К тому же, в случае изменения требований (что бывает почти всегда), не придётся переписывать всю систему или вставлять костыли на том же jQuery.
Нет, я не много пишу на бэкбоне к сожалению, но это и не чистая теория. Я вижу то что сейчас творится в проектах с jQuery без бэкбона и с бэкбоном. Второй вариант мне нравится больше, и в текущий момент, и в ближайшем будущем.

Я согласен что на jQuery можно написать код который будет просто работать, но черт возьми, в нем реально можно умереть при малейшем изменении верстки. С бэкбоном все проще в этом плане, он модульней и понятней, во всяком случае — мне. А требования у нас не меняются, тьфу-тьфу-тьфу, потому что мы не работаем на стороннего заказчика.
Что вам мешает писать модульно без бекбона?
В данный момент я разрабатываю на Backbone.Marionette довольно сложный проект с очень толстым клиент-сайдом. Честно вам скажу, на JQuery я бы такое рехнулся писать, про поддержку вообще молчу.

Ну и Coffee Script выручает.
...Backbone.Marionette…
Ну и Coffee Script выручает.

Искренне сочувствую вам.
Не стоит. Мне очень нравится.
А потом ищи кто и где повесил обработчик. В случае бэкбона все будет на своих местах. Нашел вьюху, используемые модели и радуешься жизни.
Это если одна вьюха — нашёл. А если их много, да они ещё и вложенные?
Я сейчас работаю над довольно большим проектом в кучей JS кода (только одних вьюх порядка 50). Конечно не всё так радужно как в статье, но лучше иметь дело с backbone-style кодом чем с jquery-style лапшой в таких количествах.

То что в jquery пишется в 3 строки — на бекбоне пишется в 6. В статье автор специально усложняет проект, чтоб показать что такой код легче улучать.

И да backbone далеко не идеал, но сидеть и искать баг в 10 килобайтах jquery лапши это ТО еще удовольствие.

PS. По поводу кучи файлов. Я пришел к такому методу. Создаю один JS файл на какой-то логический модуль. Внутри файла анонимная функция в которой описаны все модели, коллекции и вью модуля. Наружу обычно вывожу только класс самой общей view, который подключаю на странице.
И да backbone далеко не идеал, но сидеть и искать баг в 10 килобайтах jquery лапши это ТО еще удовольствие

Уверяю вас, лапша не зависит от того, используется ли в проекте Backbone или нет.

Наружу обычно вывожу только класс самой общей view, который подключаю на странице.

Но в таком случае, вы не сможете использовать одну и ту же модель в разных модулях.
> Уверяю вас, лапша не зависит от того, используется ли в проекте Backbone или нет.
Чисто теоретически я с Вами согласен. Но опыт моих и чужих проектов говорит о другом. И этому есть простое объяснение: для jquery нужен еще отдельный стайлгаид, иначе будет лапша в 100% случаях (так тупо быстрее). У бекбона уже есть структура, место биндинга к эвентам и прочее.
Всё выше сказанное справедливо для так сказать не профессионалов JS. Т.е. серверных разработчиков которые заодно пишут и фронтенд. Чаще всего такие разработчики не профессионалы в JS, а значит с бекбоном им будет проще писать более понятный остальным код.

> Но в таком случае, вы не сможете использовать одну и ту же модель в разных модулях.
Если понадобится можно всегда вынести модель в отдельный файл, либо просто вывести наружу
Когда поведение клиента обусловлено довольно сложной логикой, то проще работать с моделями/коллбеками, чем превращать в код в лапшу, которая работает способом, который понятен лишь для его создателя. Мне даже в прототипе приложения доводилось писать js код на 1000 строк, у которого логика, скажем так, не тривиальная. При этом страница была обычной, с точки зрения пользователя.

Я не могу сказать, что backbone был бы идеальной альтернативной, но подход «просто работает» не подходит, особенно когда нужно сильно расширять функционал.
jQuery код разносится на файлы с соглашениями по именованию и ответственности, если этого хотеть. Фабрика виджетов jQueryUI в помощь для создания модульного интерфейса. Если виджет сложный со связанными полями тогда mvc сама напрашивается и реализуется внутри виджета созданием объекта (модели) со своими set/get методами и событиями. Тут, может, поможет Backbone, но пока без него справляюсь)
Много раз слышал про jQueryUI, но не довелось потрогать, так что не могу поддержать спор :)
Возможно вы здесь правы, но мне Backbone привычней, хоть и появился смысл взглянуть на jQueryUI
И не трогайте. Слишком тяжелая. В этом плане те же бутстраповские виджеты более симпатичны.
Мне кажется здесь вопрос в подходе раз, и во-вторых, в количестве. Когда подобных запросов много, поддерживать backbone на мой взгляд проще. Он очень логичен. Все-таки весь конечный код не окажется в одном файле, а будет логично собираться и в случае проблем, будет достаточно легко определить, где проблема.

Хотя я соглашусь в вами, как бы я не любил backbone — для примера приведенного выше — второй пример намного легче и для понимания и для поддержания :) Но автор я думаю хотел донести до нас принцип.
Да, я согласен с вами насчет данного конкретного примера. Когда у вас небольшая задача и вы знаете, что вам не придется дорабатывать и развивать код, то да можно писать спагетти-код. Но во всех остальных случаях необходимо писать «правильный» код. (Под «правильным» кодом я подразумеваю не код на Backbone. Я подразумеваю код, который отвечает единому принципу ответственности, код который можно тестировать, и легко поддерживать.)
Друг мой, понимаете ли вы, во что превратится ваш «правильный» код, когда вьюх станет больше 50, а модели будут вложены друг в друга? Если вы покинете такой проект, то заберёте сакральные знания об устройстве ваших абстракций с собой, и уже никто не сможет поддерживать такой проект.
Тут не 50 штук вьюшек, но все же. Просто показать структуру. На мой взгляд она проще чем многое другое.
NodeCellar
Я правильно понимаю, что вот это всё написано для отображения 5 статичных страниц?
Ничего сложного не увидел
А представляете, что это будет за простыня кода на классическом jQuery, если в организованом виде на Backbone вьюх больше 50?
Todomvc Backbone Requirejs Example
Todomvc jQuery Example
Кода, как видно, больше, но читаемость, расширяемость и модульность в разы лучше, как по мне.
Больше кода не может быть читабельнее, если не впадать в крайности, конечно.
Модульность? Полагаю, разговор не про разные названия объектов, в которых определены методы, а про возможность повторного использования кода в других проектах. Очень интересно посмотреть, где вы будете использовать TodoModel и TodoView?
Расширяемость extend'ом-то?
Допустим нужно доработать задачу, получить сохраненные статусы. В примере с Backbone, просто добавляем ещё одну строчку `statuses.fetch();`, а пример на jQuery нужно будет переписать, и если изначально писали не вы, так сначала разобраться.
Спасибо за перевод, кода действительно много, тяжело осилить в понедельник утром :) Но зато подойдет для любого уровня знаний.
Почему бы код не запрятать под спойлер? Тогда будет значительно меньше статья, а, следовательно, менее громоздкой.
Отличная идея. Обновил статью.
Статья супер, наконец-то я понял зачем нужен backbone.
В свое время решал следующую задачу: реализовать виджет, который может строить древовидные фильтры (с поддержкой функций), для фильтрации grid'a с данными. Упрощенным примером могут служить «Расширенные сегменты» в Google Analytics.

Рассматривал вариант использовать backbone. В результате отказался, поскольку backbone не умеют реализовывать древовидные структуры ни из моделей, ни из view. Реализовал на jQuery-спагетти, о чем уже не раз пожалел. Но речь не об этом.

Может кто-то поделиться ссылочками на проекты, сделанные на backbone, но с нестандартной структурой данных (не коллекция моделей), а деревом к примеру? Или предложения, как решить описанную мной задачу с использованием backbone?
>Изменение №5
>Но при запуске в Chrome мы увидим ошибку:
>Uncaught TypeError: Cannot call method 'add' of undefined

Почему то вспомнился анекдот, где программист копирующий код пошагово с книги получил ошибку компиляции, перелазил все форума сам решил проблему, и только потом прочитал следующую страничку книги где было написано «вы увидите что код не компилируется. Поэтому давайте сделаем ...»
Only those users with full accounts are able to leave comments. Log in, please.