Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
Перечисленные автором недостатки Backbone являются продолжением его достоинств. Весь недостающий функционал добавляется модулями по мере необходимости, или не добавляется, если не нужен.
В самом деле, как и jQuery, Backbone не должен содержать все на свете возможности, для этого есть плагины.
Ну и да, Zepto и Mustache там на самом деле не нужны, автор соврал.
В самом деле, как и jQuery, Backbone не должен содержать все на свете возможности, для этого есть плагины.
Ну и да, Zepto и Mustache там на самом деле не нужны, автор соврал.
Весь недостающий функционал добавляется модулями по мере необходимости
Вопрос от Backbone-нуба − есть ли какой-то must-have набор плагинов? Например, для решения упомятой в обзоре возможной утечки памяти (если такая проблема в Backbone действительно стоит).
Память течет обычно из приложения, которое накапливает ссылки на ненужные сущности (например, View генерируется каждый раз снова, но где-то сохранилось замыкание на старый объект View).
В таком случае имеет смысл посмотреть на Marionette, она помогает лучше структурировать приложение.
Для Data binding можно использовать, например, Rivets, она отлично работает с событийной моделью моделей и коллекций Backbone, поддерживает в т.ч. похожие на Django фильтры вида
Еще я часто использую Backbone.localStorage для хранения разных вещей локально в браузере.
Все это не то чтобы must have, выбор решения зависит от поставленной задачи. В приложение размером с todomvc.com нет практического смысла тащить Marionette и Rivets, например.
В таком случае имеет смысл посмотреть на Marionette, она помогает лучше структурировать приложение.
Для Data binding можно использовать, например, Rivets, она отлично работает с событийной моделью моделей и коллекций Backbone, поддерживает в т.ч. похожие на Django фильтры вида
data-value="event.startDate | date" и вообще оставила приятное впечатление.Еще я часто использую Backbone.localStorage для хранения разных вещей локально в браузере.
Все это не то чтобы must have, выбор решения зависит от поставленной задачи. В приложение размером с todomvc.com нет практического смысла тащить Marionette и Rivets, например.
Однако впереди у меня еще так много интересного… Спасибо.
Ну вот по сути и нагороди то, что из себя представляет Angular JS. Если уж дело дошло до Marionette + Rivets, не лучше ли взять готовый инструмент, с более притертыми «комплектующими», и главное отменно работающий? (=
А если мне хочется вместо Rivets «притереть» что-то совершенно другое, или вообще оторвать нафиг?
Монолитное решение лучше, если оно абсолютно точно совпадает с решаемой задачей. Как WordPress — для блогов это превосходное решение, но попробуйте сделать на нем интернет-магазин, и встроенный функционал будет в основном мешать (помогать точно не будет).
Пожалуй, более близкий пример — столетняя священная война Django и Rails с одной стороны, и микрофреймворков с другой. Аргументацию в пользу микрофреймворков см. в любом холиварном треде схожей тематики.
Монолитное решение лучше, если оно абсолютно точно совпадает с решаемой задачей. Как WordPress — для блогов это превосходное решение, но попробуйте сделать на нем интернет-магазин, и встроенный функционал будет в основном мешать (помогать точно не будет).
Пожалуй, более близкий пример — столетняя священная война Django и Rails с одной стороны, и микрофреймворков с другой. Аргументацию в пользу микрофреймворков см. в любом холиварном треде схожей тематики.
Для backbone нужен или jQuery или Zepto
Автор пытался представить минимальный вес и привёл Zepto.
Вообще если гоняться за байтами то можно использовать zepto и кастомную сборку lodash. Получится 19.5+26.6+11.3 = 57.1 (или ~16кб после gzip). А если использовать древние версии то и того меньше…
Но я бы не советовал гоняться за байтами — почти во всех сравнениях производительности на jsperf Zepto проигрывает jQuery.
Автор пытался представить минимальный вес и привёл Zepto.
Вообще если гоняться за байтами то можно использовать zepto и кастомную сборку lodash. Получится 19.5+26.6+11.3 = 57.1 (или ~16кб после gzip). А если использовать древние версии то и того меньше…
Но я бы не советовал гоняться за байтами — почти во всех сравнениях производительности на jsperf Zepto проигрывает jQuery.
Зависимость не строгая. То есть да, неплохо иметь какую-то библиотеку для DOM-манипуляций, но сам по себе Backbone работает без нее (только Backbone.View нужна работа с DOM). Формулировка «Backbone требует как минимум...» таким образом неверна, зависимость вполне себе опциональная; «Backbone обычно используют с...» подходит гораздо лучше.
По поводу jQuery согласен, даже когда-то постил эти бенчмарки на хабр.
По поводу jQuery согласен, даже когда-то постил эти бенчмарки на хабр.
Есть еще jqMobi, правда работать эта штука будет только в современных браузерах, но по тем же тестам неслабо шустрее jQuery. В теории подружить с Backbone ее не составит особого труда.
Возможно стоит добавить какие-то критерии по работе с кодом фреймворка.
Допустим, Backbone и Ember очень похожи в том плане как они работают с классами, как определяют атрибуты, функции, биндинги.
А вот у Ангуляра совершенно свой путь, который я так и не смог понять: скоупы, ресурсы, Depenency Injection… Намного привычнее работать со стандартными View-Model-Router.
Ещё бы посоветовал взглянуть на BatmanJS. Он как мне кажется вобрал лучшее от Ангуляра и Эмбера. С одной стороны Convention over configuration, привычные Model, View, Controller, простота использования и низкий порог вхождения. С другой, он пока слабо документирован и малочисленное сообщество. Но работа с определенно фреймворком радует.
Допустим, Backbone и Ember очень похожи в том плане как они работают с классами, как определяют атрибуты, функции, биндинги.
А вот у Ангуляра совершенно свой путь, который я так и не смог понять: скоупы, ресурсы, Depenency Injection… Намного привычнее работать со стандартными View-Model-Router.
Ещё бы посоветовал взглянуть на BatmanJS. Он как мне кажется вобрал лучшее от Ангуляра и Эмбера. С одной стороны Convention over configuration, привычные Model, View, Controller, простота использования и низкий порог вхождения. С другой, он пока слабо документирован и малочисленное сообщество. Но работа с определенно фреймворком радует.
Ах да, вот ещё одно сравнение с оценочками и детальным обзором.
blog.susestudio.com/2013/03/client-side-js-mv-framework-roundup.html
Внезапно там тоже рекомендуют Ватмана )
blog.susestudio.com/2013/03/client-side-js-mv-framework-roundup.html
Внезапно там тоже рекомендуют Ватмана )
А как же Knockout? Это достойный соперник Angular и Ember, хоть и менее тяжелый
Knockout и Batman уже вспомнили. Где Kendo, где AgilityJS, где Spine, где Closure? Я не говорю про Meteor и Derby. Такое ощущение, что текст написан человеком, лично заинтересованном в продвижении CanJS.
…и в догонку (хоть пока и рановато для конкуренции с остальными) — toolkitchen.github.io
«Я использовал 4 фреймворка...» — человек пишет лишь о том, что он сам использовал, что и прилекло моё внимание для перевода. Обзор поверхностно осмотренных — совсем не то, что тобзор того, что использовал сам.
Backbone самый понятный, пожалуй, но ковырять руками приходится много. Angular впечатляет возможностями из коробки, но пугает то, что нифига не понятно сходу, как оно вообще работает. Ember выглядит стройно, но по официальной документации и туториалу у меня так и не завёлся.
Хм, странно чего не завелся. У меня все проблемы были только из-за того, что я пытался всё нахрапом в кофискрипт перевести. Кстати, у ембера есть свой кофискрипт с блекджеком и шлюхами. В ембере нужно юзать только последнюю версию. Ну и создать инстанс приложения, роута и моделек. За вечер разобрался… Вроде как… Типа того…
Я пробовал без кофескрипта. Последнюю версию. На каком-то месте оно просто вывалило в консоль каких-то невнятных ошибок из внутренностей самой библиотеки. Перечитал документацию пару раз, сравнил с тем, что у меня, и ничего не понял, кроме того, что если что, найти ошибку будет очень тяжело. В том же Angular ошибки более человечные.
А как вы сравнивали размеры?
Например, backbone:
не вижу я 18кб
Например, backbone:
58kb, Full source, tons of comments
6.3kb, Packed and gzipped
не вижу я 18кб
Скажите, если я хочу начать с изучения какого-то js-фреймворка, с чего начать? Знаю jquery достаточно хорошо.
Вопрос исходит из того, что начав с symfony в php месяц пытался в нем разобраться, хотя результат стоил этого времени
Вопрос исходит из того, что начав с symfony в php месяц пытался в нем разобраться, хотя результат стоил этого времени
Я бы посоветовал изучать backbone. Низкий порог входа, быстрый вау эффект, огромное комьюинити, большое колличество туториалов и примеров для начинающих.
Потом уже можно смотреть в сторону angular и knockout
Потом уже можно смотреть в сторону angular и knockout
И какой смысл тратить на него время если смотреть в сторону совсем других библиотек потом? Angular ни чуть не сложнее, да так же как и knockout. Проблема в том что эти фрейморки разные вещи почти совсем делают и как их люди так легко сравнивают друг с другом я не понимаю.
От чего может быть в бекбоне вау эффект? Это же просто маленькая либа, наталкивающая на способ организации кода…
В ангуляре есть dependency injection. Однозначно учить его! :)
(шутка понятная симфонистам)
(шутка понятная симфонистам)
Backbone, — вполне неплохая база.
Backbone.
Начните с изучения теории, как минимум вы должны быть в курсе про событийную модель, MVC
Специально для вас делали: angular.ru :-)
Сравнение ужасно бестолковое и бессмысленное. Давайте сравним столовое серебро с трактором и замерим это все в попугаях. Примерно так.
Логично сравнивать было либо Angular.js и Ember.js, либо добавить к ним еще backbone.js, но либо с knockout.js ( knockback.js) либо то, что советовали в оригинальной статье — marionette.js. И сюда же надо было бы добавлять meteor.js и derby.js. Тогда бы получилось хоть как то правильно. А то, что товаришь пишет, что он их использовал все 4, и потом вот так вот сравнивает, показывает, что он ни в зуб ногой где и что надо применять.
Логично сравнивать было либо Angular.js и Ember.js, либо добавить к ним еще backbone.js, но либо с knockout.js ( knockback.js) либо то, что советовали в оригинальной статье — marionette.js. И сюда же надо было бы добавлять meteor.js и derby.js. Тогда бы получилось хоть как то правильно. А то, что товаришь пишет, что он их использовал все 4, и потом вот так вот сравнивает, показывает, что он ни в зуб ногой где и что надо применять.
(Пока дописывал кончилось время редактирования.)
Либо давайте пойдем другой дорогой и будем сравнивать только определенные аспекты которые решают все перечисленные фреймворки, например двухсторонний биндинг и обсервабл, и говорить только об этом.(angular, knockout, ember, marionette) и т д
Или работа с веб сервисами — angluar, backbone, breeze, ember и т д
По большому счету сравнивать angular и ember с derby и meteor тоже в лоб нельзя, потому что в последних двух еще решаются вопросы серверной части приложения, а в первых двух нет.
Тогда бы получилось хоть как то правильно. А то, что товаришь пишет, что он их использовал все 4, и потом вот так вот сравнивает, показывает, что он ни в зуб ногой где и что надо применять.
Либо давайте пойдем другой дорогой и будем сравнивать только определенные аспекты которые решают все перечисленные фреймворки, например двухсторонний биндинг и обсервабл, и говорить только об этом.(angular, knockout, ember, marionette) и т д
Или работа с веб сервисами — angluar, backbone, breeze, ember и т д
По большому счету сравнивать angular и ember с derby и meteor тоже в лоб нельзя, потому что в последних двух еще решаются вопросы серверной части приложения, а в первых двух нет.
Тогда бы получилось хоть как то правильно. А то, что товаришь пишет, что он их использовал все 4, и потом вот так вот сравнивает, показывает, что он ни в зуб ногой где и что надо применять.
Я думаю проблема всех этих обзоров — не четко описаны юз кейсы. Хотелось бы услышать что-то в стиле: здесь лучше применить marionette, тут backbone, тут можно ангуляром и т.д.
Останусь при своем мнении: frameworks makes you stupid!
В разработке использую backbone благодаря хорошему соотношению управляемости, возможности встроить любой свой код или обработчик без лишних телодвижений и «борьбы» с фреймворком, переписыванием его же «классов».
Большинство недостатоков (например невозможности перерисовки представления без ее полной генерации, которое лечится либо дополнительным knockout, либо танцами с бубном внутри представления) покрываются полным контролем кода (ведь исходного-то не так много)
Здесь главное не забывать, что среднестатистический пользователь (не_хабрапользователь) не выдержит наворотов из зоопарка библиотек, забивающих и без того дефицитную память, заполненную всяческими нелюбимыми им тулбарами, плагинами и прочим спамом.
В разработке использую backbone благодаря хорошему соотношению управляемости, возможности встроить любой свой код или обработчик без лишних телодвижений и «борьбы» с фреймворком, переписыванием его же «классов».
Большинство недостатоков (например невозможности перерисовки представления без ее полной генерации, которое лечится либо дополнительным knockout, либо танцами с бубном внутри представления) покрываются полным контролем кода (ведь исходного-то не так много)
Здесь главное не забывать, что среднестатистический пользователь (не_хабрапользователь) не выдержит наворотов из зоопарка библиотек, забивающих и без того дефицитную память, заполненную всяческими нелюбимыми им тулбарами, плагинами и прочим спамом.
У меня стояла задача выбрать оптимальный фреймворк. В первую очередь ориентировался на поддержку крупными компаниями и размер сообщества. В итоге остановился на Knockout, хотя Angular тоже понравился. Правда knockout считается не MVC.
Забыли упомянуть, что у Ember Йехуда Кац на логотипе. :)
Ну потому так много фреймворков, чтобы вы могли выбрать для себя то что надо по вкусу.
Тут могу сказать, что подход эмбера в этом плане лучше. С одной стороны, у них двонаправленная связь (что несомненно удобно при разработке приложений — вьюхи меняются при изменении модели). С другой это релаизовано без дата-атрибутов, а в рамках шаблонизации.
Тут могу сказать, что подход эмбера в этом плане лучше. С одной стороны, у них двонаправленная связь (что несомненно удобно при разработке приложений — вьюхи меняются при изменении модели). С другой это релаизовано без дата-атрибутов, а в рамках шаблонизации.
Использую Backbone в связке с Rivets.js для data-bind (Весит ~3Кб). Очень хорошо себя показал на гигантских формах с кучей вложенных многоуровневых коллекций. Плюс ко всему Rivets можно адаптировать под любое хранилище данных, хоть под простой JavaScript объект. Рекомендую посмотреть ;-)
Если кто-то будет использовать связку Backbone+Rivets, то вам понадобится адаптор. Тот, что предлагает автор не очень — есть по лучше.
View bindings — это связывание представлений, а не представление связываний. Filtered list Views — это представления отфильтрованных списков, а не отобранный список просмотра. Как вы переводите, если не знакомы с английским порядком слов? Это же грубейшие ошибки.
Backbone крайне хорош тем, что прост и гибок. Любые кастомные штуки делать на нем — не проблема. Сообщество тоже добавляет плюсы: все ответы давно есть на стаке.
Народ, скажите, а что — ExtJS вообще не котируется у нас? :)
Почему не котируется? ExtJS используется немного для других задач просто.
Может, я чего-то не понимаю?.. Чем отличаются задачи, которые решает Ext от задач, которые решает, например, Ember?
В ExtJS есть большая библиотека готовых компонентов. Которые достаточно тяжелые. Гриды, деревья, календари, окна, чарты и т.д. При этом, все компоненты связаны в единую экосистему. Если вам нужно «десктопное приложение в браузере», то на extjs или qooxdoo стоит пристально посмотреть. ExtJS, в том числе, позволяет вам писать что-то вообще не зная html и css. За это, правда, придется расплачиваться тяжестью и неторопливостью фреймворка.
Конкретно с Ember я не знаком, но сколько на нем потребуется писать, например, редактируемый TreeGrid, который уже есть в ExtJS?
ExtJS и Qooxdoo — это тяжелые интерфейсные фреймворки-конструкторы, прежде всего.
Конкретно с Ember я не знаком, но сколько на нем потребуется писать, например, редактируемый TreeGrid, который уже есть в ExtJS?
ExtJS и Qooxdoo — это тяжелые интерфейсные фреймворки-конструкторы, прежде всего.
Я согласен, что тяжеловесность Ext-а — это, пожалуй, главная его проблема, но если для тебя не смущают 600-700 кб дополнительного веса (которые, впрочем, при желании можно почистить от неиспользуемого кода), то он предоставляет вполне неплохой набор инструментов помимо визуальных компонентов, типа TreeGrid. Те же ajax-запросы, наследование объектов, событийная система, работа с таблицами данных — всё это глубинные вещи, которые могут быть использованы уже сами по себе, без контролов.
Я вот просто для себя решил изучать Ember, на самом деле просто ради фана.
Одним из факторов был такой, что довольно известный в Сети человек – Jeff Atwood, выбрал этот фреймворк для клиентской части своего нового проекта – Discourse – форумного движка следующего поколения.
Сам я пока на стадии изучения/ковыряния. Возможно, кому-нибудь будет полезна моя Майнд-Мапа, которую я создаю в ходе изучения Ember
Одним из факторов был такой, что довольно известный в Сети человек – Jeff Atwood, выбрал этот фреймворк для клиентской части своего нового проекта – Discourse – форумного движка следующего поколения.
Сам я пока на стадии изучения/ковыряния. Возможно, кому-нибудь будет полезна моя Майнд-Мапа, которую я создаю в ходе изучения Ember
Интересно, но помимо классического паттерна MVC существуют ещё очень интересные MVP/MVVM, а также HMVC. Было бы интересно почитать о фрэймворках/библиотеках, основанных на этих паттернах.
Backbone — это и есть имплементация MVP. Аббревиатура MVC в JS фреймворках — это не какая-то конкретная парадигма, а просто обобщенное название для подходов, в которых архитектура приложения разделяется на составные части. Как минимум на data domain (модель) и presentation (представление). По этому, фреймворк, который реализует MVP или MVVM, вполне могут назвать MVC фреймворком.
Backbone — это и есть имплементация MVP.
Спасибо, буду знать.
Аббревиатура MVC в JS фреймворках — это не какая-то конкретная парадигма, а просто обобщенное название для подходов, в которых архитектура приложения разделяется на составные части. Как минимум на data domain (модель) и presentation (представление). По этому, фреймворк, который реализует MVP или MVVM, вполне могут назвать MVC фреймворком.
Жаль, что традиция называть вещи своими именами опять выходит из моды… :-(
Я всегда думал, что аббревиатура MVC в контексте программирования может означать только патерн Model-View-Controller и ни что другое, а оказывается вон оно как. Похоже кто-то принял «бритву Оккама» слишком близко к сердцу…
Люди, Backbone — не фреймворк, это библиотека.
backbonejs.org/#FAQ-why-backbone
backbonejs.org/#FAQ-why-backbone
Backbone is a library, not a framework, and plays well with others.
Писал и на Angular и на Backbone (Marionette) и могу с уверенностью отдать голос за ангуляр.
1. Кривая обучения. Бекбон может показаться проще с первого взгляда, НО! он дает совбоду действий в результате которой кодбейс превращается в что то не очень хорошее. Видел на примере реальных проектов. Например нет котроллера или медиатора, который надо бы добавить, но многие просто не делают этого, пишут в жеквери код в бекбоновских абстракциях и т.д.
Ангуряр все таки накладывает больше ограничений на разработку и нужно прочитать книжечку и доки (не саме конечно хорошие чтобы разобраться) но многие вещи в 80 процентах случаев вы сделаете ОЧЕНЬ быстро. Главное просечь ангуляр дзен.
2. Размер. Если вы используете ангуляр, то жеквери больше не нужен. Конечн если нет зависимостей на сторонние либы где без него не обойтись. В ангуляр встроен jqLite для базовых манипуляция с дом деревом, но если делать по уму то его вполне хватает.
3. Производительность. В аргуляре это большая проблема и я надеюсь что во второй вресии они будет решена, но тут нажно помнить что нельзя на одной страничке особенно на мобилке вывалить > 2000 елементов на которые навешен $watch иначе все будет очень плохо. В бексбоне все намного предскажуемей и но датабиндинг надо делать самому — никакой магии.
В общем вывод — я лафки ангуляр))
Кстати если кому интересно на гитхабе есть небольшой прототип приложения Angular + Require + Karma + Jasmine
github.com/azadorozhniy/kickstart_angular
1. Кривая обучения. Бекбон может показаться проще с первого взгляда, НО! он дает совбоду действий в результате которой кодбейс превращается в что то не очень хорошее. Видел на примере реальных проектов. Например нет котроллера или медиатора, который надо бы добавить, но многие просто не делают этого, пишут в жеквери код в бекбоновских абстракциях и т.д.
Ангуряр все таки накладывает больше ограничений на разработку и нужно прочитать книжечку и доки (не саме конечно хорошие чтобы разобраться) но многие вещи в 80 процентах случаев вы сделаете ОЧЕНЬ быстро. Главное просечь ангуляр дзен.
2. Размер. Если вы используете ангуляр, то жеквери больше не нужен. Конечн если нет зависимостей на сторонние либы где без него не обойтись. В ангуляр встроен jqLite для базовых манипуляция с дом деревом, но если делать по уму то его вполне хватает.
3. Производительность. В аргуляре это большая проблема и я надеюсь что во второй вресии они будет решена, но тут нажно помнить что нельзя на одной страничке особенно на мобилке вывалить > 2000 елементов на которые навешен $watch иначе все будет очень плохо. В бексбоне все намного предскажуемей и но датабиндинг надо делать самому — никакой магии.
В общем вывод — я лафки ангуляр))
Кстати если кому интересно на гитхабе есть небольшой прототип приложения Angular + Require + Karma + Jasmine
github.com/azadorozhniy/kickstart_angular
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение Angular, Backbone, CanJS и Ember