Что должны выбрать новички: AngularJS, Ember.js или Backbone.js?

1. AngularJS против Ember.js против Backbone.js: краткий обзор
2. Angular против Ember против Backbone: чему следует учиться начинающим JavaScript?
3. Плюсы и минусы каждой структуры
4. ПЛЮСЫ:
5. видение
6. МИНУСЫ:
7. Директивы
8. ember.js
9. ПЛЮСЫ:
10. видение
11. Компонентная модель
12. МИНУСЫ:
13. Backbone.js
14. ПЛЮСЫ:
15. МИНУСЫ:
16. Архитектура
17. Утечка памяти
18. Заключение
19. Что выбирают другие

Стоит ли использовать AngularJS, Backbone или Ember? Какие рамки должны выбрать новички? Дин Софер из AngularUI и Крейг Маккичи, автор Руководства по JavaScript-фреймворку, предлагают свое понимание этого поста.

Дин Софер

AngularJS против Ember.js против Backbone.js: краткий обзор

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

Ember был солидным проектом, но в то время Backbone был настолько популярен и имел такую ​​опору, что Ember не смог его заменить. Тем не менее, Angular взял на себя многое из того, что делает Ember, и сделал его еще проще, чем PHP, где любой тупица может писать ужасный код - люди даже не могут спорить с простотой его использования. Прежде чем я взял Angular, я попробовал другие вещи, такие как Knockout, MVC, Backbone, Ember и другие фреймворки. Я закончил с Angular, потому что он занимает меньше строк кода. В нем меньше символов, меньше строк, он короче и не использует сеттеры и геттеры для привязки данных. Для меня это намного легче обернуть мою голову вокруг. Вы можете написать scope.age = 23 и scope.name = John, и люди могут прочитать это и понять, что это по сравнению с scope.setdata (age, 23). Angular намного легче понять, за исключением случаев, когда вы начинаете создавать директивы ... это совсем другой зверь.

Раньше у Ember было преимущество в виде маршрутизатора, но UI Router в значительной степени позволил AngularJS ускорить работу, поэтому я говорю людям, что им определенно не следует создавать проекты без UI router. Поэтому в настоящее время я не вижу ничего, что заставляло бы меня выбирать Ember вместо Angular.

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

Магистраль, с другой стороны, сильно отличается от Angular. Backbone - это конструктор виджетов, который просто создает блоки HTML с привязанным к ним Javascript, и все. Все дело в функциях рендеринга в Backbone, в то время как Angular и Ember являются живыми шаблонизаторами, как и другие фреймворки, такие как Knockout. Весь движок живых шаблонов, где вы просто накладываете привязки на элементы dom и получаете данные, возвращаемые к вам в действительно легкодоступном виде, - это направление, в котором мы движемся. Я думаю, что Backbone движется в неправильном направлении, поэтому, если вы спросите меня, идти ли с Ember или Backbone, я бы сказал, Ember. Конечно, это только мое мнение, основанное на том, что я понимаю.

Codementor JavaScript Рамочные часы офиса - выбор религии: AngularJS, Backbone, Ember

Кодментатор Крейг Маккичи также имел Рабочие часы посвященный теме фреймворков JavaScript и предоставил нам более глубокий анализ:

Angular против Ember против Backbone: чему следует учиться начинающим JavaScript?

Мой путь обучения шел от jQuery до Angular, прежде чем перейти к Backbone и, наконец, к Ember. Если бы мне пришлось делать это снова, я думаю, что было бы гораздо лучше, если бы я сначала изучил Backbone.js. Некоторые люди могут быть вооружены и говорить такие вещи, как «Вы просто тратите свое время» или «Зачем изучать этот материал, который не имеет значения для JavaScript?», Но с точки зрения обучения , я думаю, это неплохо, если Вы делаете это только для того, чтобы подготовиться к реальным MVC, учитывая, как работает Backbone.js. больше похоже на библиотеку, чем на структуру , По сути, я уверен, что многие относительно новые разработчики JavaScript сталкиваются с множеством общих утверждений, в которых люди указывают, какая инфраструктура хороша, что лучше, а чего нет. Тем не менее, без некоторого контекста, в котором можно переварить эти утверждения, они в конечном итоге становятся мнением о вещах.

Мне лично нравится думать о фреймворках, разбивая их на особенности и приводя конкретные примеры, так как я думаю, что это действительно помогает понять, чего там нет. Я написал на в моем блоге ранее о том, как быстро изучить фреймворки JavaScript, и я также переписал его для SitePoint , Для быстрого примера, давайте посмотрим на функцию маршрутизации каждой платформы. Эта функция нужна вам, если вы находитесь в клиентском приложении и виртуально переключаете страницы на клиентской стороне. Таким образом, всякий раз, когда вы щелкаете ссылку или меняете URL в адресной строке, это изменение URL или изменение window.location перехватывается на клиенте, и новый виртуальный шаблон загружается с новыми данными. Здесь, в Backbone, есть действительно простой пример маршрутизации путем переключения между страницами «Домой» и «О программе»:

var HomeView = Backbone.View.extend ({template: '<h1> Home </ h1>', initialize: function () {this.render ();}, render: function () {this. $ el.html ( this.template);}}); var AboutView = Backbone.View.extend ({template: '<h1> About </ h1>', initialize: function () {this.render ();}, render: function () {this. $ el.html ( this.template);}}); var AppRouter = Backbone.Router.extend ({маршруты: {'': 'homeRoute', 'home': 'homeRoute', 'about': 'aboutRoute',}, homeRoute: function () {var homeView = new HomeView ( ); $ ("# content"). html (homeView.el);}, aboutRoute: function () {var aboutView = new AboutView (); $ ("# content"). html (aboutView.el);}} ); var appRouter = new AppRouter (); Backbone.history.start ();

JSFiddle Link

Из приведенного выше примера видно, что homeRoute имеет значение по умолчанию '', в котором браузер переходит к HomeView и загружает HTML. По сути, маршрут отображается на функцию или некоторый код JavaScript, который загружает новый конец представления, так что он похож на MVC-маршрутизатор на стороне сервера, только это происходит на клиенте. Вот как вы можете сделать маршрутизатор во встроенном провайдере Angular:

var routingExample = angular.module ('FunnyAnt.Examples.Routing', []); routingExample.controller ('HomeController', function ($ scope) {}); routingExample.controller ('AboutController', function ($ scope) {}); routingExample.config (function ($ routeProvider) {$ routeProvider. when ('/ home', {templateUrl: 'embedded.home.html', controller: 'HomeController'}). when ('/ about', {templateUrl: ' embedded.about.html ', контроллер:' AboutController '}). в противном случае ({redirectTo:' / home '});});

Ссылка JSFiddle

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

App = Ember.Application.create (); App.Router.map (function () {// первый параметр ссылается на шаблон this.route ('home', {path: '/'}); this.route ('about');});

JSFiddle Link

Как только вы поймете, что делают эти коды, вы сможете взглянуть на все фреймворки в гораздо более объективной перспективе, а также понять, что они намного более похожи, чем они отличаются. Лично я не думаю, что изучать кого-либо из них бесполезно, так как я думаю, что как только вы получите каркас, вы его получите. Все хотят, чтобы вы поверили, что используемая ими структура лучше и отличается от других, но это в основном из-за плюсы и минусы каждого каркаса. Что вам действительно нужно понять, так это концепция одностраничных приложений (SPA) и то, как JavaScript MVC-фреймворки помогают вам создавать SPA. С точки зрения кривой обучения, я думаю, что она велика во всех рамках. AngularJS может показаться пугающим, потому что раньше документация была настолько ужасной, что это было почти комично, тем более что они позволяли людям комментировать внизу, и когда вы копали их в поисках чего-то полезного, вы можете быть удивлены тем, что люди публикуют там. В наши дни AngularJS документы намного лучше. Кроме того, сообщество вокруг Angular очень большое, так что если вы спросите что-нибудь о Переполнение стека Вы получите ответ в кратчайшие сроки по сравнению с другими системами.

Однако то, насколько трудным вы найдете Angular, также будет зависеть от того, откуда вы пришли. Если вы пришли из предприятия Java или предприятия .NET, где вы используете контейнеры Inversion of Control (IoC) каждый день, и теперь, что такое внедрение зависимостей, у вас будет меньше проблем с AngularJS. Если вы пришли из креативного медиа-фона, написали код CSS и плагины jQuery, но не привыкли к корпоративным вещам, то вам может показаться более сложной задачей изучение Angular. Том Дейл отлично поработал с документацией Ember, и их веб-компоненты гораздо проще понять, чем директивы AngularJS, но когда дело доходит до получения ответов на вопросы, лично мне было немного сложнее, хотя это во многом связано с числом людей, использующих рамки. Магистраль мала, поэтому «достать» относительно просто. Поэтому, если у вас есть время, неплохо бы сначала изучить Backbone, чтобы лучше узнать, как работает MVC, поскольку, как видно из приведенных выше примеров, все фреймворки MVC довольно похожи.

Плюсы и минусы каждой структуры

AngularJS

ПЛЮСЫ:

тестирование

Если вы работаете в корпоративном магазине, особенно с опытом работы с Java или Ruby on Rails, вам действительно понравится то, что Angular предлагает в плане тестирования. В то время как другие веб-фреймворки могут поддерживать тестирование, Angular выходит за рамки этого и имеет встроенное внедрение зависимостей, что является большим плюсом для Angular, если вы действительно заботитесь о тестировании.

видение

AngularJS всегда настаивал на поддержке браузера. Кроме того, он думал о поддержке мобильных устройств раньше других платформ, наряду с ECMAScript 6 и веб-компонентами. Таким образом, команда AngularJS очень дальновидна и обладает дальновидностью.

МИНУСЫ:

Встроенный маршрутизатор

Большинство людей фактически не используют маршрутизатор в AngularJS. Конечно, есть альтернатива с открытым исходным кодом, AngularUI Router Это, в основном, устраняет эту слабость, но, если честно, сравнивая Framework с Framework прямо, Ember был первым там с действительно сильным маршрутизатором, в то время как родной маршрутизатор Angular не так хорош. Например, если у вас есть список элементов и сведения об этих элементах, в приложении Ruby on Rails вы могли бы представить / list-route, а затем / details-itemID для подробностей. Однако на самом деле люди захотят видеть список и подробности на одной странице, им может понадобиться список в левой части меню. Когда они нажимают на элемент, они ожидают, что смогут детализировать его детали. Хотя этот вид сложного взаимодействия возможен с базовым маршрутизатором Angular, вы бы на самом деле прятались и показывали вещи, которые не очень родные. У вас нет возможности поместить код в отдельное изолированное место для подробного просмотра и поместить представление списка в отдельное изолированное место.

Напротив, если у вас есть надежный маршрутизатор, как в Ember или AngularUI, у вас будет вложенное представление, где подробный маршрут будет находиться под маршрутом списка и может быть составлен или разделен во вложенной иерархии, которая является супер мощный. Кроме того, маршрутизатор Ember и AngularUI также позволяет вам иметь именованные представления, что полезно, если вы собираетесь разделить страницу на верхний и нижний колонтитулы, боковую панель, левую навигацию и т. Д. По сути, именованные представления также позволят вам иметь изолированный набор кода, контроллер (в случае Angular) и область действия для каждой из этих частей, чтобы вы могли составлять их. На родном Angular роутере такой функции нет. Команда Angular в настоящее время переписывает маршрутизатор для своей новой платформы, и подробности об этом не были опубликованы. Тем не менее, с AngularUI Router, это не должно быть проблемой при выборе используемой платформы.

Директивы

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

ember.js

ПЛЮСЫ:

Маршрутизатор

Как упоминалось ранее, встроенный маршрутизатор Ember очень сильный. Это полный конечный автомат, как и AngularUI Router для Angular.

видение

Ember отлично справился со своим видением, таким как предварительный просмотр object.observe (), следование по пути Angular, раннее обдумывание веб-компонентов и т. Д.

Компонентная модель

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

МИНУСЫ:

тестирование

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

Backbone.js

ПЛЮСЫ:

облегченный

Если у вас есть устаревшее приложение или приложение с «коричневым полем», вы хотите очистить грязный код jQuery и не определились с тем, какую инфраструктуру использовать, это может быть хорошей идеей для внедрения Backbone. Это очень мало, больше библиотеки чем фреймворк, и вы можете использовать его для рефакторинга старого кода, очистки и получения большей модульности вокруг того, что вы делаете.

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

МИНУСЫ:

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

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

Архитектура

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

Утечка памяти

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

Заключение

Что касается Angular и Ember, то это будет разумный выбор. Backbone может показаться менее предпочтительным, хотя на самом деле это связано с поколениями того, что происходило при создании богатых JavaScript-приложений. Сначала был простой старый JavaScript, в котором никто не хотел писать его, когда это было из-за всех кросс-браузерных проблем. Затем появился jQuery, и, поскольку он может быть назван библиотекой манипуляций с DOM, он устраняет проблемы кросс-браузерности. Он также имел AJAX API, который позволял многое, так что это был своего рода второй шаг в эволюции создания приложений JavaScript. Третье поколение будет Backbone и Knockout. Эти двое возникли потому, что в тот момент люди осознавали, что не могут повторно использовать код и страницы, когда пишут приложения jQuery, и им казалось, что они пишут эти вложенные коды. Конечно, они могли написать хороший код jQuery, но это не всегда приводило их к успеху. Обещания улучшают ситуацию, но вы все равно можете быстро сломать кнопку возврата, сделав несколько вызовов AJAX с вашим кодом jQuery.

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

Команда Angular в некотором роде признала эту проблему, и в версии 1.3 одной из основных функций было улучшение производительности. С другой стороны, если вы посмотрите на то, что делает команда Ember помимо инструментов разработки, вы заметите их проект HTMLbars. Это как бы революционизирует их подход к привязке данных, а также их подход к DOM и их шаблонизатор. В результате Ember стал намного быстрее. Таким образом, в ранних версиях Angular и Ember были проблемы с производительностью на мобильных устройствах, если у вас было много элементов на странице, тогда как в Backbone у вас мог быть точный контроль над вещами. В целом, какой фреймворк вы выберете, будет зависеть от того, что вы делаете с фреймворком, но, надеюсь, это даст вам простую идею.

Что выбирают другие

Для меня было бы субъективно говорить о том, что я вижу больше, но вы можете взглянуть на онлайн-статистику из github, а также на вопросы о переполнении стека, чтобы получить представление. Исходя из моего опыта, связанного с приобретением корпоративных тренировок, Angular явно имеет преимущество в популярности перед Ember, но в последние несколько недель он объявил о выходе новой версии 2.0, и Ember стал сильным. Если вы находитесь в магазине Rails и у вас много разработчиков Rails, вы можете подумать об Ember, потому что соглашения очень похожи. Это потому, что один из основных участников Ember был в основной команде jQuery и в Rails, а сейчас он является создателем Ember вместе с Томом Дейлом и другими людьми. Итак, в основном Ember очень дружелюбен к разработчикам Rails с точки зрения встроенных инструментов и опыта разработчиков. Кроме того, если вам действительно интересны URL-адреса и SEO, и вы все еще хотите использовать одну из этих многофункциональных платформ, встроенный маршрутизатор Ember сделает ее более дружественной к SEO. Однако JavaScript Framework, SPA и SEO, как правило, не совместимы, и вы можете Об этом подробнее здесь ,

Кодментатор Крейг Маккичи был разработчиком программного обеспечения в течение почти 20 лет, в основном в стеке Microsoft. В какой-то момент он был сертифицированным тренером Microsoft, хотя в последние годы он стал гораздо больше интересоваться интерфейсной разработкой (HTML, CSS и JavaScript), удобством использования и пользовательским опытом после работы в качестве консультанта в нескольких различных цифровых интерактивных агентства по проектам.

Похожие

Комментарии