Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Только что прочитал доки на их сайте, захожу на хабр, а тут эта статья, отлично :)
Специалисты, поясните пожалуйста — в чём преимущества/недостатки Ember.js перед Backbone.js. Спасибо.
Тут подробно расписаны отличия (и не только между ember и backbone) – coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/
Судя по статье, в Ember нет бОльшей части функционала Backbone. В Backbone хорошо реализованы модели, наследование, коллекции. Есть синхронизация модели с сервером из коробки. При этом они никак не завязаны на отображение. Это именно средства для описания предметной области — модели данных. С другой стороны отображения (Views) в Backbone многим кажутся громоздкими. Я думаю им стоило бы изобразительную часть сделать опциональной.
Я использую сейчас связку: Backbone + Knockout через надстройку Knockback. При этом есть еще одна надстройка над Backbone — Backbone-Relational. Более того серверная часть на NodeJS, так что модель данных для сервера и клиента у меня описывают одни и тот же файлы. Для сервера модели дополнительно расширяются. A Backbone-Relational в автомате помогает поддерживать связи между моделями. Пока что все красиво, но и не без особенностей. Knockback используется на клиенте — он просто позволяет облегчить конвертирование моделей Backbone в ViewModels Knockouta.
Я использую сейчас связку: Backbone + Knockout через надстройку Knockback. При этом есть еще одна надстройка над Backbone — Backbone-Relational. Более того серверная часть на NodeJS, так что модель данных для сервера и клиента у меня описывают одни и тот же файлы. Для сервера модели дополнительно расширяются. A Backbone-Relational в автомате помогает поддерживать связи между моделями. Пока что все красиво, но и не без особенностей. Knockback используется на клиенте — он просто позволяет облегчить конвертирование моделей Backbone в ViewModels Knockouta.
Как заявляют разработчки, ember стремится уменьшить кол-во «шаблонного кода», т.е. в нем сразу выбраны решения для типичных задач.
Основное преимущество и видимо одновременно и недостаток — это байндинги данных к Handlebars шаблонам. Что позволяет очень удобно автоматически обновлять страницу при изменениях. А с другой стороны это же накладывает некоторые ограничения на генерируемый по умолчанию html и он немного «замусоревается» служебными тегами, которые нужны ember для поддержки этой автоматики.
Ну и есть вопрос насколько гибко и быстро это будет работать в случае большого и/или сложного приложения. Хотя разработчики, вроде бы, обещают, что с этим все хорошо.
Также хорошо выглядит возможнось создавать вложенные view (пример из документации):
Это позволяет управлять довольно маленькими блоками страницы и повторно их использовать в других view.
Не могу сказать, что у меня сильно большой опыт работы с backbone и ember, но поигравшись с ними в небольших проектах, мне ember кажется удобнее и производит хорошее впечатление.
Основное преимущество и видимо одновременно и недостаток — это байндинги данных к Handlebars шаблонам. Что позволяет очень удобно автоматически обновлять страницу при изменениях. А с другой стороны это же накладывает некоторые ограничения на генерируемый по умолчанию html и он немного «замусоревается» служебными тегами, которые нужны ember для поддержки этой автоматики.
Ну и есть вопрос насколько гибко и быстро это будет работать в случае большого и/или сложного приложения. Хотя разработчики, вроде бы, обещают, что с этим все хорошо.
Также хорошо выглядит возможнось создавать вложенные view (пример из документации):
App.UserView = Ember.View.extend({
templateName: 'user',
// ...
infoView: Ember.View.extend({
templateName: 'info'
// ...
})
});
Это позволяет управлять довольно маленькими блоками страницы и повторно их использовать в других view.
Не могу сказать, что у меня сильно большой опыт работы с backbone и ember, но поигравшись с ними в небольших проектах, мне ember кажется удобнее и производит хорошее впечатление.
Ember = Sproutcore -> у Sproutcore есть dataStore и это круто
Если вторая статья ваша, то было бы хорошо, либо более полную на Русском, либо перевод той статьи, для того чтобы было все в одном месте.
Очень любопытны биндинги, которые есть в Ember.js. Это точно MVC фреймворк?
И да KnockoutJS это чистой воды MVVM, а не MVC.
И да KnockoutJS это чистой воды MVVM, а не MVC.
Все эти JS Frameworks черезчур запутанные и каждый пытается навязать свою идеологию.
Стоит ли все так усложнять на стороне клиента?
Не проще ли писать на JQuery более очевидные конструкции?
А то получается и на стороне сервера у нас MVC и на клиенте MVC. Количество кода вырастает в разы!
Где преимущество? В чем фишка? Я так и не увидел.
Стоит ли все так усложнять на стороне клиента?
Не проще ли писать на JQuery более очевидные конструкции?
А то получается и на стороне сервера у нас MVC и на клиенте MVC. Количество кода вырастает в разы!
Где преимущество? В чем фишка? Я так и не увидел.
Ты и тут можешь использовать жиквери.
Если пишешь приложение, в котором есть крудо-подобные операции (а они почти всегда есть), то очень сложно следить за data consistency в нескольких местах одновременно (появляется много говнокода, жестких зависимостей в коде), здесь помогает эмбер, и еще он помогает сериализовать данные из хтмл в js-объекты (в случае использования биндингов на инпуты), ну и еще много с чем помогает
Если пишешь приложение, в котором есть крудо-подобные операции (а они почти всегда есть), то очень сложно следить за data consistency в нескольких местах одновременно (появляется много говнокода, жестких зависимостей в коде), здесь помогает эмбер, и еще он помогает сериализовать данные из хтмл в js-объекты (в случае использования биндингов на инпуты), ну и еще много с чем помогает
Вы не натыкались в сети на open-source приложение приближенное к реальности? Или хороший пример?
опен-сорс приближенные к реальности не видел (только туду, но это так себе конечно).
из комментов в блоге эмбер знаю, что этот сайт использует его www.uniiverse.com/, но я не смотрел исходники (это не реклама:))
из комментов в блоге эмбер знаю, что этот сайт использует его www.uniiverse.com/, но я не смотрел исходники (это не реклама:))
+146!
В нативном JS есть всё что нужно для организации кода\приложения и т.п. Есть jQuery для работы с HTML-элементами. Есть Node.js для сервера.
Есть тысячи плагинов для практических целей — красивый диалог, коннектор к базе данных, работа с Canvas или обёртка для ImageMagick, да что угодно есть!
Объясните мне хоть кто-нибудь, ЗАЧЕМ вот эти монструозные фреймворки, каждый из которых, как написали выше, продвигает свою «правильную, гениальную, всё-одной-строчкой» идею?
В нативном JS есть всё что нужно для организации кода\приложения и т.п. Есть jQuery для работы с HTML-элементами. Есть Node.js для сервера.
Есть тысячи плагинов для практических целей — красивый диалог, коннектор к базе данных, работа с Canvas или обёртка для ImageMagick, да что угодно есть!
Объясните мне хоть кто-нибудь, ЗАЧЕМ вот эти монструозные фреймворки, каждый из которых, как написали выше, продвигает свою «правильную, гениальную, всё-одной-строчкой» идею?
jQuery код в более-менее сложном приложении скатиться в лапшу и все эти «тысячи плагинов» не помогут решить вопрос организации кода и создания какой-либо архитектуры. А сейчас все меньше сайтов и все больше веб-приложений со сложной логикой. И все больше кода так скажем уходит с сервера на клиент, что заставляет искать соответствующие подходы.
Да, каждый фреймворк предоставляет свой «путь». Разработчик выбирает, что ему ближе, все в общем то как и с сервер сайд фреймворками.
Да, каждый фреймворк предоставляет свой «путь». Разработчик выбирает, что ему ближе, все в общем то как и с сервер сайд фреймворками.
С «организацией кода» и «созданием какой-нибудь архитектуры» никакой фреймворк не поможет, если разработчик не понимает, как надо организовать код. А если понимает — то крупный фреймворк (в большинстве случаев) будет избыточен.
Это просто два разных подхода. И каждый имеет право на существование. Кто-то использует «низкоуровневые» библиотеки и строит фундамент самостоятельно, кто-то испольует фреймворки, которые предоставляют базис. И так не только в мире JS. Дескутировать на тему, что лучше — можно вечно.
Чуть-чуть поясню свою позицию (если кому-то интересно): я не против фреймворков, а против избыточности. Допустим, jQuery — достаточно крупный функциональный фреймворк, но в любом крупном проекте он будет задействован по-полной — и работа с HTML-структурой, и AJAX, и CSS-анимации всякие и т.п.
А в фреймворке из статьи — например, не проще ли выкинуть чепуху вида
Welcome.Book = Ember.Object.extend({
title: null,
author: null,
genre: null
});
и просто создать банальный нативный конструктор
var Book = function(){
// всяко-разно
};
Book.prototype. //дальше уж что хотите
А в фреймворке из статьи — например, не проще ли выкинуть чепуху вида
Welcome.Book = Ember.Object.extend({
title: null,
author: null,
genre: null
});
и просто создать банальный нативный конструктор
var Book = function(){
// всяко-разно
};
Book.prototype. //дальше уж что хотите
> Не проще ли писать на JQuery более очевидные конструкции?
На клиенте сейчас растет количестко кода и в больших приложениях jQuery просто не достаточно. jQuery это DOM обертка, которая никак не поможет вам организовать кодовую базу.
> А то получается и на стороне сервера у нас MVC и на клиенте MVC. Количество кода вырастает в разы!
Если честно то сейчас в некоторых случаях MVC(и модификации) более необходим оказывается на клиенте чем на сервере. Да и MVC архитектура пришла с десктопных аппликаций, а нынешний веб в ряде случаев все больше и больше напоминает десктоп.
На клиенте сейчас растет количестко кода и в больших приложениях jQuery просто не достаточно. jQuery это DOM обертка, которая никак не поможет вам организовать кодовую базу.
> А то получается и на стороне сервера у нас MVC и на клиенте MVC. Количество кода вырастает в разы!
Если честно то сейчас в некоторых случаях MVC(и модификации) более необходим оказывается на клиенте чем на сервере. Да и MVC архитектура пришла с десктопных аппликаций, а нынешний веб в ряде случаев все больше и больше напоминает десктоп.
ок, сам по себе подход мне нравится, но как насчет безопасности? Во первых это позволяет пользователям изучить ваш код (как бэ интеллектуальная собственность и всё такое), а во вторых вносить правки в этот код!
Понятно, что по хорошему все проверки на валидность поступающих данных нужно дублировать на бэкэнде. Но всёже, как насчет того, что любой может посмотреть и изучить ваш код?
Понятно, что по хорошему все проверки на валидность поступающих данных нужно дублировать на бэкэнде. Но всёже, как насчет того, что любой может посмотреть и изучить ваш код?
на стороне серваре не MVC, а REST API. Ember.js это фреймворк для одностраничных приложение прежде всего.
Из статьи заметил, что работа с моделью находится в зародишевой стадии. Вытаскивать вручную данные и заполнять коллекцию не очень удобно. Тот же backbone имеет надстройки для синхронизации данных, что делает коммуникацию с сервером более прозрачной.
Те вместо
было бы куда приятнее сделать
Те вместо
$.getJSON('data/books.json', function(data) {
data.forEach(function(item){
self.pushObject(Welcome.Book.create(item));
});
});
было бы куда приятнее сделать
Welcome.Book.load()
блин, форматирование пропало :(
Там есть свой DataStore https://github.com/emberjs/data, который как раз и позволяет делать приблизительно то, что Вы хотите
var people = App.store.findAll(App.Person);
Я не смог спокойно читать эту статью, смысл все время ускользал от меня!
В свое время приглядывался к этому фреймворку, параллельно использовал backbone. Теперь активно использую angularjs. Он для меня более прозрачный и понятный, плюс у него есть такая очень крутая киллер фитча под названием AngularJS Batarang
Вроде выглядит не плохо, да еще и от гугла, вопрос только — как жить с тем, что иде будут ругаться на невалидные атрибуты
Я предпочитаю использовать не IDE с javascript. Точнее, я пишу весь клиентский код на CoffeeScript с использованием Sublime Text 2. Однако знаю что плагин для angularjs в планах для Intellij Idea.
Ох, извиняюсь, невнимательно прочел ваш комментарий. Angular поддерживает все свои аттрибуты в формате data-название-аттрибута. Любая IDE, понимающая HTML5 не будет ругаться.
Хорошая библиотечка, только я слабо понимаю, как ее совместить со статичным контентом, на случай выключенного жс у пользователя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Начинаем работать с Ember.js