Пользователь
0,2
рейтинг
17 апреля 2013 в 23:00

Разработка → Сравнение Angular, Backbone, CanJS и Ember перевод

(Дата публикации оригинала — 12.04.2013)
Выбор JavaScript MVC фреймворка — тяжёлая работа. Нужно учесть много факторов, и число вариантов выбора может быть огромно. Достаточно взглянуть на проект ToDoMVC (о нем по-русски).

Я работал с 4 фреймворками: Angular, Backbone, CanJS и Ember. Поэтому решил сделать сравнение, чтобы помочь вам решить, какой из них использовать. Я выделю несколько факторов, которые вы можете использовать при выборе. Каждый фактор будет иметь оценку от 1 до 5 (больше — лучше). Я старался быть беспристрастным, но, конечно, оценки основаны на личном опыте.



Функции




Есть действительно важные особенности фреймворков, обеспечивающие построение основы приложений. Делает ли он связывание представлений? Двунаправленное связывание? Фильтры? Имеет вычисляемые свойства? Грязные атрибуты? Валидацию форм? (И т.д.) Это может быть очень длинный список. Ниже приводится сравнение того, что я считаю действительно важными функциями в рамках MVC:
Функции Angular Backbone CanJS Ember
Наблюдаемые (observables) y y y y
Маршрутизация (Routing) y y y y
Представление связываний (View bindings) y - y y
Двунаправленное связывание
(Two way bindings)
y - - y
Вложенные представления (Partial Views) y - y y
Отобранный список просмотра
(Filtered list Views)
y - y y
*) Observables: объекты, изменения которых отслеживаются.
*) Routing: Изменения якоря URL при изменении отслеживаемых объектов.
*) View bindings: Использование автоматически изменяемых представлений, когда наблюдаемый объект изменяется.
*) Two way bindings: Наличие автоматически изменяемых представлений, например, в полях ввода.
*) Partial views: Представления (визуализация шаблонов), включающие другие представления.
*) Filtered list views: Показ представлений по некоторым условиям.

Итак, мои оценки реализации суммы функций:
Оценки Angular Backbone CanJS Ember
Функции 5 2 4 5

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

Гибкость



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

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

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

Ember и Angular ещё до некоторой степени гибки, но обнаруживаете, что иногда придётся бороться с фреймворком, если вам не нравятся некоторые его действия. Есть вещи, которые нужно просто принять при работе с ними.
Оценки Angular Backbone CanJS Ember
Гибкость 3 5 4 3


Порог входа и документация



Angular вначале быстро создаёт вау-эффект. Он легко позволяет делать сложные вещи типа двунаправленной синхронизации. Но после того как вы узнали основы, дальше порог обучения становится выше: открывается сложная структура с большим количеством особенностей. Чтение документации затруднено из-за специфического жаргона и малого количества примеров.

Backbone — довольно прост в освоении. Но вскоре обнаруживаете, что не хватает понимания того, как лучше структурировать код. Нужно будет просмотреть или прочитать несколько учебников, чтобы познакомиться с лучшими практиками. Вы обнаружите, что, вероятно, надо узнать ещё и библиотеку надстройку типа Marionette или Thorax. Так что я не считаю, что Backbone легче изучать, чем CanJS.

CanJS — наиболее лёгкая из данной группы по обучаемости. Просто из canjs.us вы будете знать почти всё, что нужно для продуктивности. Существуют, конечно, другие средства обучения, но у меня была редкая необходимость обращения за помощью.

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

Оценки Angular Backbone CanJS Ember
Порог входа и документация 2 4 5 3


Продуктивность разработки



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

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

Backbone требует написания очень большого объёма шаблонного кода. Что, думается, совершенно ненужное и оказывается прямой угрозой производительности труда.

CanJS — не блещет и не разочаровывает. Но из-за небольшого порога вхождения вы можете получать результаты очень рано.

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

Оценки Angular Backbone CanJS Ember
Продуктивность разработки 4 2 4 5


Сообщество



Легко ли найти помощь, документацию и экспертов?

Backbone. Сообщество огромно. Очень активно на StackOverflow и IRC. Десятки учебников и пособий.

Angular, Ember. Довольно большие сообщества, так же деятельно на StackOverflow и IRC, но объёмом поменьше.

CanJS. Сообщество мало по сравнению с другими, но, к счастью, достаточно активно и полезно. Я не нашел оснований считать меньший размера сообщества CanJS минусом.

Оценки Angular Backbone CanJS Ember
Сообщество 4 5 3 4


Инфраструктура (экосистема)



Что такое инфраструктура (или экосистема) плагинов или библиотек?
Здесь снова Backbone даёт всем фору — для неё есть куча плагинов. Экосистема Angular начинает быть интересной с её вещами типа Angular UI. Думаю, что экосистема Ember развивается меньше, хотя должна бы быть лучше, из-за её популярности. у CanJS — инфраструктура развита меньше остальных.

Оценки Angular Backbone CanJS Ember
Инфраструктура 4 5 2 4


Размер



Он может быть важным фактором для мобильных разработок.
Angular Backbone CanJS Ember
Размер 80K 18K 33K 141K
Backbone — самый маленький, и об этом часто упоминают. Но это ещё не всё.
Angular Backbone CanJS Ember
Зависимости Единственная библиотека, не требующая зависимостей Требует как минимум Underscore и Zepto. Небольшой шаблонизатор есть в Underscore, но вы захотите более качественный, типа Mustache. Вместе — 61K Требует как минимум Zepto — 57K требует jQuery и Handlebars. Имеем 269K

Оценки Angular Backbone CanJS Ember
Размер 4 5 5 2


Производительность



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

Я видел и сделал сам много тестов производительности с этими библиотеками (один пример). Но я не совсем уверен в достоверности этих тестов. Это довольно сложно — убедиться, что тест проверяет правильные вещи и в правильном направлении.

Из того, что я видел в тестах и читал, CanJS, похоже, имеет преимущество, особенно в привязке View к данным. С другой стороны, считаю, что Angular менее производителен на том основании, что он делает «грязную проверку» объектов. Это не может быть так же быстро, как у других. Смотреть тест.
Оценки Angular Backbone CanJS Ember
Производительность 3 4 5 4


Зрелость



Зрелый ли это фреймворк, показал ли он себя в производстве, много ли сайтов используют его?

Backbone имеет массу сайтов со своим использованием. Его кодовая база — уже 2 года без серьёзных изменений, это отличная вещь в плане зрелости.

Ember — не слишком новая, но в процессе доработок серьёзно менялась, а последняя стабильность измеряется парой месяцев. В этот раз я не считаю фреймворк зрелым.

Angular кажется более стабильным и проверенным, чем Ember. Но не настолько, как Backbone.

CanJS — может показаться, что решение непроверенное, потому что нет массы сайтов с ней. Но она существует гораздо дольше. Она — «вытяжка» из библиотеки JavaScriptMVC, существующей с 2008 года и имеет большой опыт встроенного использования.
Оценки Angular Backbone CanJS Ember
Зрелость 4 5 4 3


Защищённость от утечек памяти


Это — важный фактор для длительно открытых одностраничных приложений. Вы же не хотите, чтобы это стало проблемой. К сожалению это легко случается, особенно, при самостоятельном создании обработчиков событий DOM.

Angular, CanJS и Ember будут обходить проблемы эффективно, как будто Вы пользуетесь только передовым опытом. Backbone требует от вас делать эту работу своевременного удаления обработчиков.
Оценки Angular Backbone CanJS Ember
Защищённость от утечек памяти 5 3 5 5


Персональные вкусы


Вероятно, это — самый значительный фактор в выборе фреймворка.
Если нравится... декларативный HTML движок на шаблонах строго придерживаться традиционного паттерна SmallTalk MVC жёсткий фреймворк
то выбирают... Angular Backbone CanJS Ember
Плюс, популярны на данный момент — Ember, Angular.
Нет способа оценить вкусы.

Итоговый подсчёт


Теперь сведём всё это вместе в итоговую таблицу для подсчёта. Помните, что это — только моё мнение. Пожалуйста, дайте знать, если вы думаете, что я собрал таблицу весов неправильно. Если поставить одинаковый вес каждого фактора в этой жёсткой конкуренции, то не выиграет практически ни один фреймворк.

От переводчика: у автора вычисляемая таблица (наподобие Excel/Calc) встроена прямо в текст, в которой читатель 1 кликом может отключить или изменить вес каждой строчки. У нас — мы можем посмотреть на таблицу с равными факторами здесь, а изменить — на странице JsFiddle по ссылке.
Оценки Angular Backbone CanJS Ember
Функции 5 2 4 5
Гибкость 3 5 4 3
Порог входа и документация 2 4 5 3
Продуктивность разработки 4 2 4 5
Сообщество 4 5 3 4
Ecosystem 4 5 2 4
Размер 4 5 5 2
Производительность 3 4 5 4
Зрелость 4 5 4 3
Защита от утечек памяти 5 3 5 5
Сумма 38 40 41 38
Если вы желаете выбрать весовые коэффициенты по собственным оценкам и предпочтениям, перейдите на авторскую вычисляемую таблицу на JsFiddle: jsfiddle.net/sporto/5JVxh/light. Там можно будет как изменить значимость каждой строчки, так и оценку автора по каждому из факторов.

Таким образом, я предполагаю, что всё зависит от личного вкуса или от значимости каждого фактора для вас.

Замечание о Backbone


Я не могу закончить пост без такого замечания. Бекбон была великолепной библиотекой 2 года назад, но сейчас есть вещи лучше. Я уверен, что много людей выбирают Бекбон исключительно из её популярности, а это — порочный круг.

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

Автор: Sebastian Porto, github.com/sporto.
Какой из этих фреймворков для вас — лидер по сумме удобств?

Проголосовал 2341 человек. Воздержалось 1953 человека.

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

Перевод: Sebastian Porto
spmbt @spmbt
карма
159,5
рейтинг 0,2
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (62)

  • +9
    Перечисленные автором недостатки Backbone являются продолжением его достоинств. Весь недостающий функционал добавляется модулями по мере необходимости, или не добавляется, если не нужен.

    В самом деле, как и jQuery, Backbone не должен содержать все на свете возможности, для этого есть плагины.

    Ну и да, Zepto и Mustache там на самом деле не нужны, автор соврал.
    • 0
      Весь недостающий функционал добавляется модулями по мере необходимости

      Вопрос от Backbone-нуба − есть ли какой-то must-have набор плагинов? Например, для решения упомятой в обзоре возможной утечки памяти (если такая проблема в Backbone действительно стоит).
      • +2
        Память течет обычно из приложения, которое накапливает ссылки на ненужные сущности (например, View генерируется каждый раз снова, но где-то сохранилось замыкание на старый объект View).
        В таком случае имеет смысл посмотреть на Marionette, она помогает лучше структурировать приложение.

        Для Data binding можно использовать, например, Rivets, она отлично работает с событийной моделью моделей и коллекций Backbone, поддерживает в т.ч. похожие на Django фильтры вида data-value="event.startDate | date" и вообще оставила приятное впечатление.

        Еще я часто использую Backbone.localStorage для хранения разных вещей локально в браузере.

        Все это не то чтобы must have, выбор решения зависит от поставленной задачи. В приложение размером с todomvc.com нет практического смысла тащить Marionette и Rivets, например.
        • +1
          Однако впереди у меня еще так много интересного… Спасибо.
        • 0
          Ну вот по сути и нагороди то, что из себя представляет Angular JS. Если уж дело дошло до Marionette + Rivets, не лучше ли взять готовый инструмент, с более притертыми «комплектующими», и главное отменно работающий? (=
          • +1
            А если мне хочется вместо Rivets «притереть» что-то совершенно другое, или вообще оторвать нафиг?

            Монолитное решение лучше, если оно абсолютно точно совпадает с решаемой задачей. Как WordPress — для блогов это превосходное решение, но попробуйте сделать на нем интернет-магазин, и встроенный функционал будет в основном мешать (помогать точно не будет).

            Пожалуй, более близкий пример — столетняя священная война Django и Rails с одной стороны, и микрофреймворков с другой. Аргументацию в пользу микрофреймворков см. в любом холиварном треде схожей тематики.
    • 0
      Для backbone нужен или jQuery или Zepto
      Автор пытался представить минимальный вес и привёл Zepto.
      Вообще если гоняться за байтами то можно использовать zepto и кастомную сборку lodash. Получится 19.5+26.6+11.3 = 57.1 (или ~16кб после gzip). А если использовать древние версии то и того меньше…
      Но я бы не советовал гоняться за байтами — почти во всех сравнениях производительности на jsperf Zepto проигрывает jQuery.
      • 0
        Зависимость не строгая. То есть да, неплохо иметь какую-то библиотеку для DOM-манипуляций, но сам по себе Backbone работает без нее (только Backbone.View нужна работа с DOM). Формулировка «Backbone требует как минимум...» таким образом неверна, зависимость вполне себе опциональная; «Backbone обычно используют с...» подходит гораздо лучше.

        По поводу jQuery согласен, даже когда-то постил эти бенчмарки на хабр.
        • 0
          еще юзается $.ajax в синке
          • 0
            Да, верно.
            Отредактировать сообщение я не могу, но да, следует читать вместо «Zepto и Mustache» просто «Mustache» — эта выдуманная «зависимость» уж точно целиком на совести автора.
      • 0
        Есть еще jqMobi, правда работать эта штука будет только в современных браузерах, но по тем же тестам неслабо шустрее jQuery. В теории подружить с Backbone ее не составит особого труда.
  • +3
    Возможно стоит добавить какие-то критерии по работе с кодом фреймворка.
    Допустим, Backbone и Ember очень похожи в том плане как они работают с классами, как определяют атрибуты, функции, биндинги.
    А вот у Ангуляра совершенно свой путь, который я так и не смог понять: скоупы, ресурсы, Depenency Injection… Намного привычнее работать со стандартными View-Model-Router.

    Ещё бы посоветовал взглянуть на BatmanJS. Он как мне кажется вобрал лучшее от Ангуляра и Эмбера. С одной стороны Convention over configuration, привычные Model, View, Controller, простота использования и низкий порог вхождения. С другой, он пока слабо документирован и малочисленное сообщество. Но работа с определенно фреймворком радует.
  • 0
    Ах да, вот ещё одно сравнение с оценочками и детальным обзором.
    blog.susestudio.com/2013/03/client-side-js-mv-framework-roundup.html
    Внезапно там тоже рекомендуют Ватмана )
  • +4
    А как же Knockout? Это достойный соперник Angular и Ember, хоть и менее тяжелый
    • 0
      Knockout хорош, сам к нему присматривался.
    • 0
      Здесь сравнение архитектурных фреймворков. Knockout — это всего-лишь либа для data-binding, которая никак не поможет в создании каркаса приложения.
  • –3
    Knockout и Batman уже вспомнили. Где Kendo, где AgilityJS, где Spine, где Closure? Я не говорю про Meteor и Derby. Такое ощущение, что текст написан человеком, лично заинтересованном в продвижении CanJS.
    • 0
      …и в догонку (хоть пока и рановато для конкуренции с остальными) — toolkitchen.github.io
    • +9
      «Я использовал 4 фреймворка...» — человек пишет лишь о том, что он сам использовал, что и прилекло моё внимание для перевода. Обзор поверхностно осмотренных — совсем не то, что тобзор того, что использовал сам.
      • 0
        Если судить по фактическим ошибкам (см. комментарии к оригинальному посту, например) и никак не следующему из статьи выводу, это обзор четырех весьма поверхностно осмотренных фреймворков.
  • +3
    Backbone самый понятный, пожалуй, но ковырять руками приходится много. Angular впечатляет возможностями из коробки, но пугает то, что нифига не понятно сходу, как оно вообще работает. Ember выглядит стройно, но по официальной документации и туториалу у меня так и не завёлся.
    • 0
      Хм, странно чего не завелся. У меня все проблемы были только из-за того, что я пытался всё нахрапом в кофискрипт перевести. Кстати, у ембера есть свой кофискрипт с блекджеком и шлюхами. В ембере нужно юзать только последнюю версию. Ну и создать инстанс приложения, роута и моделек. За вечер разобрался… Вроде как… Типа того…
      • 0
        Я пробовал без кофескрипта. Последнюю версию. На каком-то месте оно просто вывалило в консоль каких-то невнятных ошибок из внутренностей самой библиотеки. Перечитал документацию пару раз, сравнил с тем, что у меня, и ничего не понял, кроме того, что если что, найти ошибку будет очень тяжело. В том же Angular ошибки более человечные.
        • 0
          Тут соглашусь. Тоже долго дебажил из-за того, что скобки зафтыкал проставить (а кофискрипт в этом плане расслабляет). И тоже никакого внятного меседжа :(
  • +1
    А как вы сравнивали размеры?
    Например, backbone:

    58kb, Full source, tons of comments
    6.3kb, Packed and gzipped


    не вижу я 18кб
    • 0
      and gzipped

      Наверное, сравнивался непожатый минифицированный размер.
  • 0
    Скажите, если я хочу начать с изучения какого-то js-фреймворка, с чего начать? Знаю jquery достаточно хорошо.
    Вопрос исходит из того, что начав с symfony в php месяц пытался в нем разобраться, хотя результат стоил этого времени
    • +3
      Я бы посоветовал изучать backbone. Низкий порог входа, быстрый вау эффект, огромное комьюинити, большое колличество туториалов и примеров для начинающих.
      Потом уже можно смотреть в сторону angular и knockout
      • 0
        И какой смысл тратить на него время если смотреть в сторону совсем других библиотек потом? Angular ни чуть не сложнее, да так же как и knockout. Проблема в том что эти фрейморки разные вещи почти совсем делают и как их люди так легко сравнивают друг с другом я не понимаю.
      • 0
        От чего может быть в бекбоне вау эффект? Это же просто маленькая либа, наталкивающая на способ организации кода…
    • +9
      В ангуляре есть dependency injection. Однозначно учить его! :)
      (шутка понятная симфонистам)
      • 0
        Там ещё и с рефлексией! :)
    • +2
      Backbone, — вполне неплохая база.
    • 0
      Backbone.
    • –1
      Начните с изучения теории, как минимум вы должны быть в курсе про событийную модель, MVC
    • +1
      todomvc.com/

      Посмотрите на код, может что то больше понравится…
    • 0
      Специально для вас делали: angular.ru :-)
  • +4
    Сравнение ужасно бестолковое и бессмысленное. Давайте сравним столовое серебро с трактором и замерим это все в попугаях. Примерно так.
    Логично сравнивать было либо Angular.js и Ember.js, либо добавить к ним еще backbone.js, но либо с knockout.js ( knockback.js) либо то, что советовали в оригинальной статье — marionette.js. И сюда же надо было бы добавлять meteor.js и derby.js. Тогда бы получилось хоть как то правильно. А то, что товаришь пишет, что он их использовал все 4, и потом вот так вот сравнивает, показывает, что он ни в зуб ногой где и что надо применять.
    • 0
      (Пока дописывал кончилось время редактирования.)

      Либо давайте пойдем другой дорогой и будем сравнивать только определенные аспекты которые решают все перечисленные фреймворки, например двухсторонний биндинг и обсервабл, и говорить только об этом.(angular, knockout, ember, marionette) и т д
      Или работа с веб сервисами — angluar, backbone, breeze, ember и т д

      По большому счету сравнивать angular и ember с derby и meteor тоже в лоб нельзя, потому что в последних двух еще решаются вопросы серверной части приложения, а в первых двух нет.

      Тогда бы получилось хоть как то правильно. А то, что товаришь пишет, что он их использовал все 4, и потом вот так вот сравнивает, показывает, что он ни в зуб ногой где и что надо применять.
    • +4
      Я думаю проблема всех этих обзоров — не четко описаны юз кейсы. Хотелось бы услышать что-то в стиле: здесь лучше применить marionette, тут backbone, тут можно ангуляром и т.д.
  • +2
    Останусь при своем мнении: frameworks makes you stupid!
    В разработке использую backbone благодаря хорошему соотношению управляемости, возможности встроить любой свой код или обработчик без лишних телодвижений и «борьбы» с фреймворком, переписыванием его же «классов».
    Большинство недостатоков (например невозможности перерисовки представления без ее полной генерации, которое лечится либо дополнительным knockout, либо танцами с бубном внутри представления) покрываются полным контролем кода (ведь исходного-то не так много)

    Здесь главное не забывать, что среднестатистический пользователь (не_хабрапользователь) не выдержит наворотов из зоопарка библиотек, забивающих и без того дефицитную память, заполненную всяческими нелюбимыми им тулбарами, плагинами и прочим спамом.
  • 0
    У меня стояла задача выбрать оптимальный фреймворк. В первую очередь ориентировался на поддержку крупными компаниями и размер сообщества. В итоге остановился на Knockout, хотя Angular тоже понравился. Правда knockout считается не MVC.
  • +1
    Забыли упомянуть, что у Ember Йехуда Кац на логотипе. :)
  • 0
    А поясните мне, будьте добры, кто знает. В том же Angular приходится вставлять де-факто код в разметку (ng-model итп). То есть у нас в HTML получается привязка к скриптам, как ни крути. В Backbone этого нет и мне нравится, что там этого нет. Я (или даже не я) делаю вёрстку отдельно, вообще особо не думая о том, какой в итоге программный код будет этим всем делом управлять. А в Angular получается, что и HTML-разметка и JS-код связаны в обоих направлениях, так сказать; в Backbone направление связи только одно — в скриптах используются селекторы DOM для шаблонов итп. Вроде бы как во-первых всегда считалось, что код и всё остальное лучше разделять, во-вторых я лично субъективно считаю, что так удобней. Чего я не знаю/не понимаю? :)
    • +1
      Ну потому так много фреймворков, чтобы вы могли выбрать для себя то что надо по вкусу.
      Тут могу сказать, что подход эмбера в этом плане лучше. С одной стороны, у них двонаправленная связь (что несомненно удобно при разработке приложений — вьюхи меняются при изменении модели). С другой это релаизовано без дата-атрибутов, а в рамках шаблонизации.
  • +4
    Использую Backbone в связке с Rivets.js для data-bind (Весит ~3Кб). Очень хорошо себя показал на гигантских формах с кучей вложенных многоуровневых коллекций. Плюс ко всему Rivets можно адаптировать под любое хранилище данных, хоть под простой JavaScript объект. Рекомендую посмотреть ;-)
    • +1
      Если кто-то будет использовать связку Backbone+Rivets, то вам понадобится адаптор. Тот, что предлагает автор не очень — есть по лучше.
      • 0
        Спасибо, что поделились своими наработками
  • +1
    View bindings — это связывание представлений, а не представление связываний. Filtered list Views — это представления отфильтрованных списков, а не отобранный список просмотра. Как вы переводите, если не знакомы с английским порядком слов? Это же грубейшие ошибки.
  • 0
    Backbone крайне хорош тем, что прост и гибок. Любые кастомные штуки делать на нем — не проблема. Сообщество тоже добавляет плюсы: все ответы давно есть на стаке.
  • 0
    Народ, скажите, а что — ExtJS вообще не котируется у нас? :)
    • 0
      Почему не котируется? ExtJS используется немного для других задач просто.
      • –2
        Может, я чего-то не понимаю?.. Чем отличаются задачи, которые решает Ext от задач, которые решает, например, Ember?
        • +1
          В ExtJS есть большая библиотека готовых компонентов. Которые достаточно тяжелые. Гриды, деревья, календари, окна, чарты и т.д. При этом, все компоненты связаны в единую экосистему. Если вам нужно «десктопное приложение в браузере», то на extjs или qooxdoo стоит пристально посмотреть. ExtJS, в том числе, позволяет вам писать что-то вообще не зная html и css. За это, правда, придется расплачиваться тяжестью и неторопливостью фреймворка.

          Конкретно с Ember я не знаком, но сколько на нем потребуется писать, например, редактируемый TreeGrid, который уже есть в ExtJS?

          ExtJS и Qooxdoo — это тяжелые интерфейсные фреймворки-конструкторы, прежде всего.
          • 0
            Я согласен, что тяжеловесность Ext-а — это, пожалуй, главная его проблема, но если для тебя не смущают 600-700 кб дополнительного веса (которые, впрочем, при желании можно почистить от неиспользуемого кода), то он предоставляет вполне неплохой набор инструментов помимо визуальных компонентов, типа TreeGrid. Те же ajax-запросы, наследование объектов, событийная система, работа с таблицами данных — всё это глубинные вещи, которые могут быть использованы уже сами по себе, без контролов.
            • 0
              «он предоставляет вполне неплохой набор инструментов помимо визуальных компонентов»
              Да, пожалуйста. Только заплатите $300 за голову разработчика.
              Но, имхо, это стрельба из пушки по воробьям. Для этого как раз и существуют другие фреймворки. К тому же бесплатные.
  • +1
    Я вот просто для себя решил изучать Ember, на самом деле просто ради фана.
    Одним из факторов был такой, что довольно известный в Сети человек – Jeff Atwood, выбрал этот фреймворк для клиентской части своего нового проектаDiscourse – форумного движка следующего поколения.

    Сам я пока на стадии изучения/ковыряния. Возможно, кому-нибудь будет полезна моя Майнд-Мапа, которую я создаю в ходе изучения Ember
  • 0
    Интересно, но помимо классического паттерна MVC существуют ещё очень интересные MVP/MVVM, а также HMVC. Было бы интересно почитать о фрэймворках/библиотеках, основанных на этих паттернах.
    • 0
      Backbone — это и есть имплементация MVP. Аббревиатура MVC в JS фреймворках — это не какая-то конкретная парадигма, а просто обобщенное название для подходов, в которых архитектура приложения разделяется на составные части. Как минимум на data domain (модель) и presentation (представление). По этому, фреймворк, который реализует MVP или MVVM, вполне могут назвать MVC фреймворком.
      • 0
        Backbone — это и есть имплементация MVP.

        Спасибо, буду знать.

        Аббревиатура MVC в JS фреймворках — это не какая-то конкретная парадигма, а просто обобщенное название для подходов, в которых архитектура приложения разделяется на составные части. Как минимум на data domain (модель) и presentation (представление). По этому, фреймворк, который реализует MVP или MVVM, вполне могут назвать MVC фреймворком.

        Жаль, что традиция называть вещи своими именами опять выходит из моды… :-(
        Я всегда думал, что аббревиатура MVC в контексте программирования может означать только патерн Model-View-Controller и ни что другое, а оказывается вон оно как. Похоже кто-то принял «бритву Оккама» слишком близко к сердцу…
  • +3
    Люди, Backbone — не фреймворк, это библиотека.
    backbonejs.org/#FAQ-why-backbone
    Backbone is a library, not a framework, and plays well with others.
  • +1
    Писал и на Angular и на Backbone (Marionette) и могу с уверенностью отдать голос за ангуляр.
    1. Кривая обучения. Бекбон может показаться проще с первого взгляда, НО! он дает совбоду действий в результате которой кодбейс превращается в что то не очень хорошее. Видел на примере реальных проектов. Например нет котроллера или медиатора, который надо бы добавить, но многие просто не делают этого, пишут в жеквери код в бекбоновских абстракциях и т.д.
    Ангуряр все таки накладывает больше ограничений на разработку и нужно прочитать книжечку и доки (не саме конечно хорошие чтобы разобраться) но многие вещи в 80 процентах случаев вы сделаете ОЧЕНЬ быстро. Главное просечь ангуляр дзен.

    2. Размер. Если вы используете ангуляр, то жеквери больше не нужен. Конечн если нет зависимостей на сторонние либы где без него не обойтись. В ангуляр встроен jqLite для базовых манипуляция с дом деревом, но если делать по уму то его вполне хватает.

    3. Производительность. В аргуляре это большая проблема и я надеюсь что во второй вресии они будет решена, но тут нажно помнить что нельзя на одной страничке особенно на мобилке вывалить > 2000 елементов на которые навешен $watch иначе все будет очень плохо. В бексбоне все намного предскажуемей и но датабиндинг надо делать самому — никакой магии.

    В общем вывод — я лафки ангуляр))

    Кстати если кому интересно на гитхабе есть небольшой прототип приложения Angular + Require + Karma + Jasmine
    github.com/azadorozhniy/kickstart_angular

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