Angular.js Backbone.js или который имеет лучшую производительность

Ответ 1

Любой, кто утверждает, что одно решение быстрее или медленнее, чем другое, либо мало знает о какой-либо из этих библиотек или фреймворков (или вообще тестирует тестирование), либо является лжецом.

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

• качество тестового/эталонного кода
• качество кода библиотеки/рамки
• тип приложения
• качество кода приложения
• используется браузер
• клиент hw
• другие процессы, выполняемые одновременно на клиенте hw
• качество и скорость подключения к Интернету
• загрузка сервера и производительность сервера
• и список можно продолжать и продолжать...

но что более важно, что именно вы подразумеваете под действием производительности? производительность - очень широкий термин, который охватывает слишком много вещей, в том числе:

• время, необходимое для загрузки приложения
• время, необходимое для ответа на действие пользователя
• использование ресурсов (cpu/memory/network)
• производительность манипуляции dom, выполняемая библиотекой/каркасом/кодом приложения
• удобство коллекционера мусора
• и снова список можно продолжать и продолжать...

Лучший способ ответить на ваш вопрос - создать приложение, которое хорошо отражает приложение, которое вы намереваетесь создавать и реализовывать с конкурирующими библиотеками/фреймами. Затем напишите качественный сканак, который будет сравнивать их голова к голове в стабильной среде.

Это, очевидно, очень трудоемкая задача, и только кто-то, кто поставил на карту, взял бы на себя это дело.

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

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

Что касается фактического сравнения между Backbone и AngularJS, вы сравниваете два очень разных решения.

Магистраль не выполняет никаких манипуляций с домино для вас, поэтому скорость вашего приложения будет в основном зависеть от того, насколько хорошо вы можете выполнять манипуляции с dom (это ваш опыт?).

AngularJS делает большую часть манипуляции с домом для вас, и у нас есть много опыта в этой области, поэтому, если вы не очень хороши, вам будет трудно найти нас.

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

Misko написал длинный пост о том, как Angular выполняет свое волшебное наблюдение за мутацией модели. Поэтому я не буду повторять это здесь. Но в основном производительность приложения AngularJS напрямую связана с количеством и сложностью привязок, используемых в текущем представлении приложения. Имея это в виду, вы можете легко предсказать производительность Angular. Еще лучше то, что с помощью таких инструментов, как расширение AngularJS Batarang для Chrome, мы позволяем вам легко управлять вашим приложением и понимать, какие привязки на странице медленны, и это позволяет сосредоточиться на исправлении частей вашего кода, которые действительно имеют значение.

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

И самое последнее: тесты часто вводят в заблуждение, но проверьте эти и возьмите их с солью.

• Backbone + Ember: http://jsfiddle.net/jashkenas/CGSd5/
• AngularJS: http://jsfiddle.net/mhevery/vYknU/23/

Ответ 2

Вы можете сделать позвоночник быстрее, если вы разделите его до минимума. Я удалил ссылку подчеркивания или lodash из магистрали, сделав ее более легкой и изменив свои события, чтобы использовать bean и в значительной степени enderjs libs минус morpheus, я поменял ее на твиновую подсветку.

Я расскажу вам об этом своей wayyyyy быстрее, чем angular. Загрузка страниц в миллисекундах против секунд.

Вещь с angular заключается в том, что шаблон проектирования MVVM медленный, потому что у вас есть тонна прямого взаимодействия с DOM. JavaScript быстро работает без DOM. Поэтому используйте DOM как можно меньше, и это невозможно с MVVM.

Лучше всего разделить вашу логику с очень маленькими быстрыми и легкими DOM-ссылками, использование указателей, когда вы можете, всегда является лучшим вариантом. Я использовал и рассмотрел каждую линию линейных строк. Запаситесь, вы получите примерно такую ​​же производительность, измените другую историю.

Базовый ресурс раздувается, и большинство движков шаблонов работают медленно. Поэтому используйте dotjs для шаблонов, используйте ender, а не jQuery, используйте bean для пользовательских событий.

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

Я выполнил jsperfs практически для всех фреймворков и библиотек, известных JS. Я создаю рамки для жизни. Да, есть выделенные переменные, но если все сделано правильно, я бы выбрал основу в любой день недели. MVVM будет вымирать... MVP - это то, где он находится, когда дело касается интерфейсных платформ.

Ответ 3

Ниже приведено сравнение производительности Angular, Ember и KO:

http://jsperf.com/angular-vs-knockout-vs-ember/2

Явный победитель в этом случае Angular, но, как было сказано ранее, тесты производительности редко бывают понятными или справедливыми.

Ответ 4

также посмотрите на нокауты. Посмотрите видео, чтобы понять, как MVVM работает в мире javascript.

http://knockoutjs.com/

Я использовал его для нескольких проектов и до сих пор очень доволен этим. Я вижу, что это часть нового ASP.NET MVC 4 (SPA) и поддерживается Microsoft.

Ответ 5

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

http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/

Для того, что стоит, Angular JS и Ember JS обращаются ко мне прежде всего из-за того, что их использование привязки очень похоже на механизм привязки Flex (на высоком уровне) И он оставляет HTML, который в основном отделен от контроллера/модели логика.

Ответ 6

Тангенциальная, но релевантная информация о том, что @igor-minar уже сказал в fooobar.com/questions/42913/...

Было несколько примеров, когда я столкнулся с проблемами производительности, которые связаны с тем, что обсуждается здесь. И эти примеры не включали никаких фреймворков (за пределами ядра jQuery для доступа к DOM).

У нас было несколько компонентов пользовательского интерфейса, которые мы строили, моделировали и рендерили в дерево DOM, состоящее из большого количества элементов. Javascript и DOM имеют присущую характеристику производительности, которая считывает блоки DOM-атрибутов при любых ожидающих обновления DOM [1]. Например, если вы измените 5 атрибутов CSS одного элемента, которые браузер может поставить в очередь и выполнить позже, а затем попытаться прочитать один атрибут CSS, ему необходимо завершить ожидающие записи DOM, прежде чем он сможет вернуть вам один атрибут просто читать. Например, простые сценарии, такие как чтение элемента element.offsetHeight, могут быть дорогими, потому что для этого требуется, чтобы DOM завершил ожидающие обновления, а затем измеряет и компонует элементы, прежде чем он сможет определить высоту конкретного элемента.

У нас было много кода, который был написан без учета этой базовой характеристики. Для его исправления необходимо было оптимизировать его таким образом, чтобы свести к минимуму блокировку чтения DOM. Кроме того, создание DOM-поддеревов в автономном режиме, прежде чем прикреплять их к документу, помогло в некоторых случаях.

При всех этих настройках мы по-прежнему не могли получить такую ​​производительность, какую нам нужны для сценариев, таких как большие списки (например, просмотр списка прокрутки, который может содержать несколько тысяч элементов списка, каждый из которых состоит из нескольких элементов DOM, чтобы получить желаемый визуальный стиль). Здесь нам пришлось изменить код для виртуализации списка и отобразить только подмножество элементов DOM, которые были фактически видны в списке [2].

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

лучше

-

Литература:

[1]. http://shop.oreilly.com/product/9780596802806.do Прочтите главу 3 по сценариям DOM

[2]. https://github.com/shyam-habarakada/js-virtual-list-view

Ответ 7

Победители http://jsperf.com/angular-vs-ember-vs-backbone-vs-canjs-vs-knockout/24

Angular выигрывает http://jsperf.com/angular-vs-ember-vs-backbone-vs-canjs-vs-knockout/23

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

Ответ 8

Не сравнивается с базой и Angular. Тем не менее, поделился своим реальным опытом, который у меня был с одним и тем же приложением - приложение среднего размера, с SPA. Сначала мы использовали Backbone и выполнили множество функций. Более продуктивный и понятный код, чем прямая запись в JS/jQuery. Через год мы переместились в angularjs. Переписал все в angular, теперь у нас около 140 директив, контроллеров и сервисов. Качество кода и производительность намного лучше. Но это не так быстро, как одно приложение в позвоночнике. Теперь просто наблюдаем за объектом. Возьмитесь в хромированном режиме для повышения громкости. Команда Angularjs должна следить за углом исполнения.

Прежде чем выбрать структуру, вы должны хорошо прочитать, где она подходит. Если ваш ответ json тяжелый со слишком большим количеством attrs, и слишком много таких объектов будут живы в любое время, angular будет медленным. Там Backbone выигрывает, но опять же, вам нужно управлять многими вещами, кодовым качеством и шаблонами себя с Backbone.