Ember.js или Backbone.js для серверной части Restful [закрыто]

98

Я уже знаю, что ember.js - более тяжелый подход по сравнению с backbone.js. Я прочитал много статей об обоих.

Я спрашиваю себя, какой фреймворк работает проще в качестве интерфейса для бэкэнда rails rest. Для backbone.js я видел разные подходы к вызову бэкэнда отдыха. Что касается ember, мне кажется, что мне нужно включить еще несколько библиотек, таких как «данные» или «ресурсы». Почему для этого есть две библиотеки?

Так что лучший выбор? Примеров соединения интерфейса с серверной частью тоже не так много. Какой хороший рабочий пример для этого вызова backend rest:

URI: ../restapi/topics ПОЛУЧИТЬ учетные данные для авторизации: admin / secrect формат: json

Робин Верух
источник
3
Должен любить вопрос, который «неконструктивный», но полезный, хорошо продуманный ответ все же получил 240+ голосов.
Эндрю

Ответы:

257

Вопреки распространенному мнению, Ember.js - это не «более тяжелый подход» к Backbone.js. Это разные инструменты, предназначенные для совершенно разных конечных продуктов. Сладкое место Ember - это приложения, в которых пользователь будет держать приложение открытым в течение длительного периода времени, возможно, весь день, а взаимодействие с представлениями приложения или базовыми данными вызывает глубокие изменения в иерархии представлений. Ember больше Backbone, но благодаря Expires, Cache-Controlэто имеет значение только на первой загрузки. После двух дней ежедневного использования эти лишние 30 КБ будут затенены передачей данных, и раньше, если ваш контент будет включать изображения.

Backbone идеально подходит для приложений с небольшим количеством состояний, где иерархия представлений остается относительно плоской и где пользователь имеет тенденцию обращаться к приложению нечасто или на более короткие периоды времени. Код Backbone должен оставаться коротким и понятным, потому что он предполагает, что данные, поддерживающие DOM, будут выброшены, а оба элемента будут собраны в памяти: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Меньший размер Backbone также делает его более подходящим для кратких взаимодействий.

Приложения, которые люди пишут в обоих фреймворках, отражают эти варианты использования: приложения Ember.js включают веб-панель управления Square , Zendesk (по крайней мере, интерфейс агента / продажи билетов) и планировщик Groupon : все приложения, с которыми пользователь может работать весь день.

Базовые приложения больше ориентированы на краткие или случайные взаимодействия, которые часто представляют собой просто небольшие разделы более крупной статической страницы: airbnb , Khan Academy , карта и списки Foursquare .

Вы можете использовать Backbone для создания приложений, на которые нацелен Ember (например, Rdio ), путем а) ​​увеличения объема кода приложения, за который вы несете ответственность, чтобы избежать таких проблем, как утечки памяти или зомби-события (я лично не рекомендую этот подход) или б) путем добавления сторонних библиотек, таких как backbone.marionette или Coccyx - многие из этих библиотек пытаются предоставить аналогичные перекрывающиеся функции, и вы, вероятно, в конечном итоге соберете свой собственный каркас, который больше и требует большего количества связующего кода, чем если бы вы просто использовали Ember.

В конечном итоге на вопрос, «что использовать», есть два ответа.

Во-первых, «Что я должен использовать, как правило, в своей карьере»: и то, и другое, точно так же, как вы в конечном итоге изучите любые инструменты, специфичные для работы, которую вы захотите использовать в будущем. Вы бы никогда не спросили: «Магистраль или D3?»; «Backbone or Ember» - столь же глупый вопрос.

Во-вторых, «Что конкретно мне следует использовать в моем следующем проекте»: зависит от проекта. Оба будут одинаково легко взаимодействовать с сервером Rails. Если ваш следующий проект включает сочетание страниц, генерируемых сервером, с так называемыми «островками богатства», предоставляемыми JavaScript, используйте Backbone. Если в вашем следующем проекте все взаимодействие переносится в среду браузера, используйте Ember.

Трек Гловацки
источник
4
Отличный ответ, Трек. Просто хотел прокомментировать здесь это Expiresи Cache-Controlпомочь гораздо меньше, чем люди думают, особенно с точки зрения мобильных устройств, которые часто их игнорируют. Я помню, что одна из версий iOS их полностью игнорировала (но все же слушала манифест кеша HTML5). Кроме того, эти значения заголовков не помогут при первом посещении пользователя - что обычно является наиболее важным при принятии решения о том, останется ли пользователь и будет ли использовать ваше приложение. Сказать, что вся разница в файлах 30 КБ не кажется мне такой уж большой проблемой. Разница в 30k необработанная или уменьшенная и сжатая с помощью gzip?
Mauvis Ledford
11
Если вы посмотрите на реальные приложения, которые созданы в стиле Ember, вы обнаружите, что от этих надоедливых килобайт никуда не деться. Либо они исходят от Ember, а код вашего приложения меньше, либо они исходят из базовых плагинов, либо они исходят из кода, который вы пишете сами. Wunderlist , который, как вы могли подумать, будет «простыми» часами при передаче около 300 КБ. Я мог бы предположить, что он был бы аналогичного размера с Ember, возможно, меньше - я никогда не писал точную копию Wunderlist, я не могу сказать со 100% уверенностью.
Trek Glowacki
1
Я согласен, мое самое популярное базовое приложение работает с 178 КБ + шаблонов, сжатых и уменьшенных. Просто указываю, что нам не следует полагаться на кеширование браузера.
Mauvis Ledford
2
Trek, вы хорошо разбираетесь в анализе использования Backbone в приложениях с расширенными шаблонами использования и сложным управлением состоянием. Я прошел через опыт преобразования устаревшего приложения в Backbone и должен был сделать именно то, что вы указали. Нам нужно было интегрировать Marionette, а также написать много связующего кода для таких вещей, как предварительная и последующая фильтрация маршрута, устранение утечки памяти и улучшенное управление событиями.
Майк Клаймер
9
«Вы бы никогда не спросили Backbone или D3» - конечно, но я легко могу представить проект, в котором я бы использовал D3 вместе с Backbone. Наверное, гораздо сложнее представить проект, в котором Backbone и Ember используются вместе на одной странице. Так что вопрос «Backbone или Ember» я считаю вполне справедливым. Вот еще один пост, который я нашел довольно информативным, потому что он сравнивает две структуры более глубоко: net.tutsplus.com/tutorials/javascript-ajax/…
Shiprack
26

Чтобы дать краткий, упрощенный ответ: в настоящий момент для бэкэнда RESTful вы должны использовать Backbone.

Чтобы дать более сложный ответ: это действительно зависит от того, что вы делаете. Как уже говорили другие, Ember предназначен для разных целей и понравится разным людям. Мой короткий ответ основан на том, что вы включили требование RESTful.

На данный момент Ember-Data (который, кажется, является механизмом сохранения по умолчанию в Ember) далек от производственной готовности. Это означает, что в нем довольно много ошибок и, что особенно важно, он не поддерживает вложенные URI (например, / posts / 2 / comments / 4556). Если REST является вашим требованием, вам придется пока обойти это, если вы выберете Ember (т.е. вам придется либо взломать его, подождать, реализовать что-то вроде Ember-Data с нуля самостоятельно, либо использовать не -очень-RESTful URI). Ember-Data не является частью Ember, поэтому это вполне возможно.

Основные различия между ними, помимо размера, заключаются в следующем:

Ember старается сделать для вас как можно больше, чтобы вам не приходилось писать столько кода. Он очень иерархичен и, если ваше приложение также очень иерархично, вероятно, вам подойдет. Поскольку это так много для вас, может быть трудно выяснить, откуда берутся ошибки, и объяснить, почему происходит неожиданное поведение (есть много «волшебства»). Если у вас есть приложение, которое естественно вписывается в тип приложения, которое Ember ожидает от вас, это, скорее всего, не будет проблемой.

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

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

Bengillies
источник
5
«что очень важно, не поддерживает вложенные URI (например, / posts / 2 / comments / 4556)» Вот соответствующий коммит, сделанный пару недель назад: github.com/emberjs/data/commit/… . Он знает, что может быть трудно не отставать от быстро меняющейся предварительной версии, но мы всегда должны стремиться к точности, когда говорим авторитетно и даем совет!
Trek Glowacki
Хорошо, спасибо. Обновил свой ответ. Я предполагаю, что это произошло в результате большого слияния отношений на прошлой неделе или около того. Я просмотрел и прочитал перечисленные изменения, но не смог найти упоминания об URL-адресах, а проблемы, которые я отслеживал, были еще открыты, когда я их проверял. Спасибо, что указали на коммит - его может быть трудно найти, не зная о его существовании.
bengillies
Это действительно из недавнего слияния ветки улучшения отношений. Мы медленно отслеживаем старые проблемы и закрываем их на этой неделе.
Trek Glowacki
3

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

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

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

Вы также можете послушать этот подкаст, в котором Джереми Ашкенас, создатель Backbone, и Иегуда Кац, участник Ember, обсуждают

Николас Зозол
источник
2
Спасибо. Что вы можете сказать о расширениях ember. Лучше использовать данные или ресурсы? Вы можете привести простой пример вызова rest api?
Робин Веруч
1
Короткий ответ: библиотеки постоянно меняются, и я не могу дать вам ответ, основанный на моем предыдущем опыте (я делал это на себе для оценки). Думаю, этот пост расскажет вам больше, чем я могу: stackoverflow.com/questions/8623091/ember-js-rest-api
Николас Зозол
1
Я уже видел этот пост. Вот почему я спросил :)
Робин Веруч
2
@NicolasZozol, какой подкаст? ссылка на сайт ?
deepak
3
javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas еще в феврале. Это было до того, как стало ясно, что эти фреймворки на самом деле не существовали в пересекающихся областях. Вы можете слышать, как Иегуда и Джереми просто разговаривают друг с другом, не делая никаких сравнений.
Trek Glowacki