5 ms·

Backbone vs. Simple JavaScript Inheritance

61 points by wx196 13y ago

cdata 13y ago
Backbone's 'extend' is portable to non-Backbone classes[1]. It would be more interesting to see the performance profile comparison of Backbone and Resig implementations of extend when used to inherit from the same class (either an empty class, or a Backbone class). [1] https://github.com/documentcloud/backbone/blob/master/backbone.js#L1530-L1561 https://github.com/documentcloud/backbone/blob/master/backbo...
- reissbaker 13y ago
  I was also bothered by the fact that the two were instantiating very different objects, so I forked the tests and added a new case that uses Backbone's portable extend method to create vanilla objects: http://jsperf.com/backbone-vs-john-resig-class/5 http://jsperf.com/backbone-vs-john-resig-class/5 TL;DR: the Backbone approach has similar performance characteristics compared to Resig's when instantiating similar objects. In some browsers (Firefox Nightly, Safari), Backbone's approach is significantly faster. It's also compatible with strict mode — although Backbone itself doesn't use strict mode — whereas Resig's uses arguments.callee which will throw errors.
weego 13y ago
I don't understand the relevance of this. Perhaps I'm being thick, but comparing a simple lightweight demo of sample inheritance and the initiation of a comprehensive framework object seems to have no valuable point other than showing that frameworks are generally slower than things much simpler than they are, which everyone should be aware of. Even then, 94k ops a second for Backbone isn't to shabby considering how many instances anyone sane will be maintaining on a page at once.
asuth 13y ago
For our recently launched flashcards tool, we built it in Backbone. Demo: http://quizlet.com/23770911/flashcards http://quizlet.com/23770911/flashcards Our experience was that backbone was very helpful in laying out code and providing clean event triggering, but that a lot of it was simply too slow to use. We started out with a View per card, but that was impossibly slow with 100+ cards (and we need to support ~1000+). We ended up with just one view for the Card section, and a view each for the sidebar and options sections. That made it much faster, but also took away many of the benefits of backbone. We also ran into significant speed problems with model gets and sets. Initializing the data for 200 cards (~10 attributes per card) took hundreds of milliseconds on Chrome and other browsers. We ended up using plain javascript objects for the hottest parts of that code. Overall to us, backbone was probably worth it, but also cost us many long days of performance debugging, and we're still not 100% happy with it. For our next project we may try something else.
- knowtheory 13y ago
  I am surprised by your experience, as there are Backbone projects which have used considerably more objects to no ill effect. Backbone's three major components, Models/Collections, Views and Events do take some planning to coordinate effectively, but that's part of laying out your application. Also, using bare JS objects is not an anti-pattern in Backbone. Use Models/Collections when you need to manage data, Views when you need to monitor parts of the DOM, and Events to manage messages between your components. Apply as necessary. P.S. Model.get is literally a single line of bare JS object property access: http://backbonejs.org/docs/backbone.html#section-38 http://backbonejs.org/docs/backbone.html#section-38 but if you have a lot of events, or validations conditioned to fire on attribute changes, that may effect how long it takes your setters to run (http://backbonejs.org/docs/backbone.html#section-41 http://backbonejs.org/docs/backbone.html#section-41 )
  - asuth 13y ago
    Thanks for the note -- the performance problem was in set(), not get (that was lazy of me). We didn't have a lot of triggers running -- we spent a lot of time looking at performance traces. Just initializing models on page load was incredibly slow. It was particularly bad on a retina iPad.
- EdwardMSmith 13y ago
  Did you use Backbone-relational for nested/related models? I've found that it has a significant performance penalty with lots of models.
  - asuth 13y ago
    No we didn't.
- deleted 13y ago
  [deleted]
- just2n 13y ago
  Backbone uses jQuery's event delegation, so there should've been minor differences between the two cases you describe, mostly with how listening to the Models/Collections worked. Additionally, it sounds like you might've been binding a render to a change in the collection? In that case, you'd want to debounce the render or only start listening to changes after the view is actually rendered with data (say the parent only renders that view when it has the data for the 200 cards, then the subview listens for changes on the collection it's given).
spicyj 13y ago
I don't understand how the code snippets are at all equivalent. It looks like ResigsClass doesn't extend anything except Class itself whereas myModel extends Backbone.Model which presumably starts off more complicated.
- just2n 13y ago
  Yes. This is precisely the problem. The inheritance model used by Backbone will be significantly more performant in terms of method calls, in general, because it doesn't implement a `super` concept. The construction should also favor Backbone's model since it doesn't create the function wrappers (in the non-trivial case, anyway). Look at what Backbone's `extend` does: https://github.com/documentcloud/backbone/blob/master/backbone.js#L1530 https://github.com/documentcloud/backbone/blob/master/backbo... The subclass's constructor calls the parent's constructor function, just as in Resig's, however Resig's `Class` is: this.Class = function(){}; Whereas `Backbone.Model` looks like this: https://github.com/documentcloud/backbone/blob/master/backbone.js#L246 https://github.com/documentcloud/backbone/blob/master/backbo... It's not hard to predict the outcome of this "benchmark."
msoad 13y ago
Web developer spend too much time worrying about JavaScript performance I think. When one method can iterate around 100000 element in a second and the other 120000 elements, I would choose one that I am more comfortable with not the faster.
- fizzbuzzd 13y ago
  Plus the fact that most performance issues come from DOM manipulation.
VeejayRampay 13y ago
I perfectly understand the need to poo-poo a Javascript framework/library in this day and age of fierce client-side competition, the submitter must have an agenda and that's perfectly OK, but come on people, let's try a little harder now, the comparing of apples and lawn chairs is getting ridiculous.
jchavannes 13y ago
Why not just use normal JavaScript inheritance? http://jsperf.com/backbone-vs-john-resig-class/10 http://jsperf.com/backbone-vs-john-resig-class/10
- valtron 13y ago
  I don't know why, but on FF21, your approach is 9% slower than resig.
snowpalmer 13y ago
As a curiosity I added one to compare against spine as well. http://jsperf.com/backbone-vs-john-resig-class/9 http://jsperf.com/backbone-vs-john-resig-class/9 However, since most of the time I'm using spine via coffeescript the inheritance is going to be done slightly different.

61 points by wx196 13y ago

cdata 13y ago

Backbone's 'extend' is portable to non-Backbone classes[1]. It would be more interesting to see the performance profile comparison of Backbone and Resig implementations of extend when used to inherit from the same class (either an empty class, or a Backbone class). [1] https://github.com/documentcloud/backbone/blob/master/backbone.js#L1530-L1561 https://github.com/documentcloud/backbone/blob/master/backbo...

reissbaker 13y ago
I was also bothered by the fact that the two were instantiating very different objects, so I forked the tests and added a new case that uses Backbone's portable extend method to create vanilla objects: http://jsperf.com/backbone-vs-john-resig-class/5 http://jsperf.com/backbone-vs-john-resig-class/5 TL;DR: the Backbone approach has similar performance characteristics compared to Resig's when instantiating similar objects. In some browsers (Firefox Nightly, Safari), Backbone's approach is significantly faster. It's also compatible with strict mode — although Backbone itself doesn't use strict mode — whereas Resig's uses arguments.callee which will throw errors.

weego 13y ago

I don't understand the relevance of this. Perhaps I'm being thick, but comparing a simple lightweight demo of sample inheritance and the initiation of a comprehensive framework object seems to have no valuable point other than showing that frameworks are generally slower than things much simpler than they are, which everyone should be aware of. Even then, 94k ops a second for Backbone isn't to shabby considering how many instances anyone sane will be maintaining on a page at once.

asuth 13y ago

For our recently launched flashcards tool, we built it in Backbone. Demo: http://quizlet.com/23770911/flashcards http://quizlet.com/23770911/flashcards Our experience was that backbone was very helpful in laying out code and providing clean event triggering, but that a lot of it was simply too slow to use. We started out with a View per card, but that was impossibly slow with 100+ cards (and we need to support ~1000+). We ended up with just one view for the Card section, and a view each for the sidebar and options sections. That made it much faster, but also took away many of the benefits of backbone. We also ran into significant speed problems with model gets and sets. Initializing the data for 200 cards (~10 attributes per card) took hundreds of milliseconds on Chrome and other browsers. We ended up using plain javascript objects for the hottest parts of that code. Overall to us, backbone was probably worth it, but also cost us many long days of performance debugging, and we're still not 100% happy with it. For our next project we may try something else.

knowtheory 13y ago
I am surprised by your experience, as there are Backbone projects which have used considerably more objects to no ill effect. Backbone's three major components, Models/Collections, Views and Events do take some planning to coordinate effectively, but that's part of laying out your application. Also, using bare JS objects is not an anti-pattern in Backbone. Use Models/Collections when you need to manage data, Views when you need to monitor parts of the DOM, and Events to manage messages between your components. Apply as necessary. P.S. Model.get is literally a single line of bare JS object property access: http://backbonejs.org/docs/backbone.html#section-38 http://backbonejs.org/docs/backbone.html#section-38 but if you have a lot of events, or validations conditioned to fire on attribute changes, that may effect how long it takes your setters to run (http://backbonejs.org/docs/backbone.html#section-41 http://backbonejs.org/docs/backbone.html#section-41 )
- asuth 13y ago
  Thanks for the note -- the performance problem was in set(), not get (that was lazy of me). We didn't have a lot of triggers running -- we spent a lot of time looking at performance traces. Just initializing models on page load was incredibly slow. It was particularly bad on a retina iPad.
EdwardMSmith 13y ago
Did you use Backbone-relational for nested/related models? I've found that it has a significant performance penalty with lots of models.
- asuth 13y ago
  No we didn't.
deleted 13y ago
[deleted]
just2n 13y ago
Backbone uses jQuery's event delegation, so there should've been minor differences between the two cases you describe, mostly with how listening to the Models/Collections worked. Additionally, it sounds like you might've been binding a render to a change in the collection? In that case, you'd want to debounce the render or only start listening to changes after the view is actually rendered with data (say the parent only renders that view when it has the data for the 200 cards, then the subview listens for changes on the collection it's given).

spicyj 13y ago

I don't understand how the code snippets are at all equivalent. It looks like ResigsClass doesn't extend anything except Class itself whereas myModel extends Backbone.Model which presumably starts off more complicated.

just2n 13y ago
Yes. This is precisely the problem. The inheritance model used by Backbone will be significantly more performant in terms of method calls, in general, because it doesn't implement a `super` concept. The construction should also favor Backbone's model since it doesn't create the function wrappers (in the non-trivial case, anyway). Look at what Backbone's `extend` does: https://github.com/documentcloud/backbone/blob/master/backbone.js#L1530 https://github.com/documentcloud/backbone/blob/master/backbo... The subclass's constructor calls the parent's constructor function, just as in Resig's, however Resig's `Class` is: this.Class = function(){}; Whereas `Backbone.Model` looks like this: https://github.com/documentcloud/backbone/blob/master/backbone.js#L246 https://github.com/documentcloud/backbone/blob/master/backbo... It's not hard to predict the outcome of this "benchmark."

msoad 13y ago

Web developer spend too much time worrying about JavaScript performance I think. When one method can iterate around 100000 element in a second and the other 120000 elements, I would choose one that I am more comfortable with not the faster.

fizzbuzzd 13y ago
Plus the fact that most performance issues come from DOM manipulation.

VeejayRampay 13y ago

I perfectly understand the need to poo-poo a Javascript framework/library in this day and age of fierce client-side competition, the submitter must have an agenda and that's perfectly OK, but come on people, let's try a little harder now, the comparing of apples and lawn chairs is getting ridiculous.

jchavannes 13y ago

Why not just use normal JavaScript inheritance? http://jsperf.com/backbone-vs-john-resig-class/10 http://jsperf.com/backbone-vs-john-resig-class/10

valtron 13y ago
I don't know why, but on FF21, your approach is 9% slower than resig.

snowpalmer 13y ago

As a curiosity I added one to compare against spine as well. http://jsperf.com/backbone-vs-john-resig-class/9 http://jsperf.com/backbone-vs-john-resig-class/9 However, since most of the time I'm using spine via coffeescript the inheritance is going to be done slightly different.