От JQuery до Backbone

[Nigrimmist]

Скролл умер.
А если серьёзно, то код сложно читать с этими плюсами и минусами. Может можно как-то цветом обозначить? И да, спасибо за труд.

[UseRifle]

Похоже, подсветка кода на Хабре не умеет отображать синтаксис diff. Я к диффам привык, очень информативно, хотя статью пока еще не до конца осилил.

[evnuh]

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

[resurection]

Очень интересна тема, но из-за плюсов-минусов не смог осилить статью.

[leshaogonkov]

Не знаю, мне нравится ваша идея с ±

[nayjest]

Поддерживаю подход и использованием diff. Даже без подсветки это удобнее, чем просто код.

[creage]

Вы забыли добавить ссылку на автора.

[iKBAHT]

Добавил и перенес в хаб переводы.

[twenty]

А теперь, внимание, главный вопрос: зачем?

[INCWADRA]

Автор как бы намекает

Этот код является более легким в обслуживании, его легче повторно использовать и расширять, и проще тестировать.

[twenty]

Вы действительно считаете, что вот это

Скрытый текст

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('');
            }
        });
    });
});

Я вовсе не хочу сказать, что второй пример — элегантный. Но если выбирать наименьшее из двух зол — второй пример намного лучше.

[antonydevanchi]

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

В jQuery же всегда одна и та же проблема — спагетти-код, который, как бы ты не старался будет удерживать рост фронтенда и душить проект.

[twenty]

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

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

[antonydevanchi]

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

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

[melik]

Что вам мешает писать модульно без бекбона?

[Agatov]

В данный момент я разрабатываю на Backbone.Marionette довольно сложный проект с очень толстым клиент-сайдом. Честно вам скажу, на JQuery я бы такое рехнулся писать, про поддержку вообще молчу.

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

[twenty]

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

Искренне сочувствую вам.

[Agatov]

Не стоит. Мне очень нравится.

[dizer]

А потом ищи кто и где повесил обработчик. В случае бэкбона все будет на своих местах. Нашел вьюху, используемые модели и радуешься жизни.

[twenty]

Это если одна вьюха — нашёл. А если их много, да они ещё и вложенные?

[nightstalker]

Я сейчас работаю над довольно большим проектом в кучей JS кода (только одних вьюх порядка 50). Конечно не всё так радужно как в статье, но лучше иметь дело с backbone-style кодом чем с jquery-style лапшой в таких количествах.

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

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

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

[twenty]

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

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

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

Но в таком случае, вы не сможете использовать одну и ту же модель в разных модулях.

[nightstalker]

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

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

[AndryX]

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

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

[boolive]

jQuery код разносится на файлы с соглашениями по именованию и ответственности, если этого хотеть. Фабрика виджетов jQueryUI в помощь для создания модульного интерфейса. Если виджет сложный со связанными полями тогда mvc сама напрашивается и реализуется внутри виджета созданием объекта (модели) со своими set/get методами и событиями. Тут, может, поможет Backbone, но пока без него справляюсь)

[antonydevanchi]

Много раз слышал про jQueryUI, но не довелось потрогать, так что не могу поддержать спор :)
Возможно вы здесь правы, но мне Backbone привычней, хоть и появился смысл взглянуть на jQueryUI

[nightstalker]

И не трогайте. Слишком тяжелая. В этом плане те же бутстраповские виджеты более симпатичны.

[Pruntoff]

Мне кажется здесь вопрос в подходе раз, и во-вторых, в количестве. Когда подобных запросов много, поддерживать backbone на мой взгляд проще. Он очень логичен. Все-таки весь конечный код не окажется в одном файле, а будет логично собираться и в случае проблем, будет достаточно легко определить, где проблема.

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

[iKBAHT]

Да, я согласен с вами насчет данного конкретного примера. Когда у вас небольшая задача и вы знаете, что вам не придется дорабатывать и развивать код, то да можно писать спагетти-код. Но во всех остальных случаях необходимо писать «правильный» код. (Под «правильным» кодом я подразумеваю не код на Backbone. Я подразумеваю код, который отвечает единому принципу ответственности, код который можно тестировать, и легко поддерживать.)

[twenty]

Друг мой, понимаете ли вы, во что превратится ваш «правильный» код, когда вьюх станет больше 50, а модели будут вложены друг в друга? Если вы покинете такой проект, то заберёте сакральные знания об устройстве ваших абстракций с собой, и уже никто не сможет поддерживать такой проект.

[Pruntoff]

Тут не 50 штук вьюшек, но все же. Просто показать структуру. На мой взгляд она проще чем многое другое.
NodeCellar

[twenty]

Я правильно понимаю, что вот это всё написано для отображения 5 статичных страниц?

[webportal]

Ничего сложного не увидел

[enleur]

А представляете, что это будет за простыня кода на классическом jQuery, если в организованом виде на Backbone вьюх больше 50?
Todomvc Backbone Requirejs Example
Todomvc jQuery Example
Кода, как видно, больше, но читаемость, расширяемость и модульность в разы лучше, как по мне.

[twenty]

Больше кода не может быть читабельнее, если не впадать в крайности, конечно.
Модульность? Полагаю, разговор не про разные названия объектов, в которых определены методы, а про возможность повторного использования кода в других проектах. Очень интересно посмотреть, где вы будете использовать TodoModel и TodoView?
Расширяемость extend'ом-то?

[RubaXa]

Допустим нужно доработать задачу, получить сохраненные статусы. В примере с Backbone, просто добавляем ещё одну строчку `statuses.fetch();`, а пример на jQuery нужно будет переписать, и если изначально писали не вы, так сначала разобраться.

[MoranXP]

Спасибо за перевод, кода действительно много, тяжело осилить в понедельник утром :) Но зато подойдет для любого уровня знаний.

[MorrisDecker]

Почему бы код не запрятать под спойлер? Тогда будет значительно меньше статья, а, следовательно, менее громоздкой.

[iKBAHT]

Отличная идея. Обновил статью.

[2tl]

Статья супер, наконец-то я понял зачем нужен backbone.

[devoto13]

В свое время решал следующую задачу: реализовать виджет, который может строить древовидные фильтры (с поддержкой функций), для фильтрации grid'a с данными. Упрощенным примером могут служить «Расширенные сегменты» в Google Analytics.

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

Может кто-то поделиться ссылочками на проекты, сделанные на backbone, но с нестандартной структурой данных (не коллекция моделей), а деревом к примеру? Или предложения, как решить описанную мной задачу с использованием backbone?

[nolka]

Автор! Вы — человек-патч! :]

[Fedcomp]

>Изменение №5
>Но при запуске в Chrome мы увидим ошибку:
>Uncaught TypeError: Cannot call method 'add' of undefined

Почему то вспомнился анекдот, где программист копирующий код пошагово с книги получил ошибку компиляции, перелазил все форума сам решил проблему, и только потом прочитал следующую страничку книги где было написано «вы увидите что код не компилируется. Поэтому давайте сделаем ...»