Как стать автором
Обновить

Комментарии 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

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

Публикации

Изменить настройки темы

Истории