3 ms·

This is important to remember but hopefully not relevant. If you have event handlers on each card instead of delegating them to the container, that's a performa

by asolove 13y ago

This is important to remember but hopefully not relevant. If you have event handlers on each card instead of delegating them to the container, that's a performance problem all by itself.

vonseel 13y ago
Can you clarify what you mean here? If I were writing a Backbone app, you mean I should bind to data attributes or similar instead of creating a new view for each item in a list?
- asolove 13y ago
  If you have a list of thousands of items, attaching event handlers to each of those items separately is relatively expensive, although it makes the view code nicer. If you are as serious about performance as these people, you would want to add delegated events on the parent level. There is a writeup about doing this in Backbone [1] although I can't vouch for it. In fairness, getting really good dom performance out of Backbone is hard because of the lack of built-in delegated event support and the non-synchronized redraws. If you have big apps that need to be super-fast, either read up on dom performance practices and adopt some helper libraries along with Backbone, or try a framework that has its own draw cycle and delegated event support. [1] http://lostechies.com/derickbailey/2011/10/11/backbone-js-getting-the-model-for-a-clicked-element/ http://lostechies.com/derickbailey/2011/10/11/backbone-js-ge...
  - crescentfresh 13y ago
    > getting really good dom performance out of Backbone is hard because of the lack of built-in delegated event support It actually is builtin: https://github.com/jashkenas/backbone/blob/1.1.0/backbone.js#L1072 https://github.com/jashkenas/backbone/blob/1.1.0/backbone.js... In fact it takes a bit of effort to not use event delegation when setting up your events dict.
    - asolove 13y ago
      Well, Backbone handles delegation for elements within the same view. But it doesn't handle the case where you have lots of instances of the same view class in a list and want each handler registered only once for the whole list. You can do this manually by checking out the event target and maintaining a mapping from dom nodes to views, which you ought to do if you have lists of hundreds or thousands of repeated subviews. But Ember and various Backbone plugins can do this for you automatically.
      - crescentfresh 13y ago
        > it doesn't handle the case where you have lots of instances of the same view Wait I'm getting confused. Didn't the title post and your linked article both say not to do this if performance is the goal? (See "Tuesday" in OP). Isn't that what we're talking about here? Sorry if I misunderstood.
        asolove 13y ago
        Yeah, I think this is just a terminology problem. Let's just lay out the complete answer: if you have a list of 1000 things to render in the same way, you can make it faster in various ways: 1. Don't render all of them at once, use pagination or infinite scroll. 2. Don't attach dom events to each item individually, instead attaching one event listener to the list container and having a way to go from the event's target to the appropriate view to act on. 3. Don't even create a view object for each item, just render them with the same template and have a composite view that knows how to act on each item's model for the delegated events. It's important to understand the relative performance benefits of these changes. #1 will make things faster in proportion to how much the page size is smaller the the full list size. #2 will reduce the number of DOM calls by a factor of the number of items in the list. #3 will reduce the number of JavaScript objects created. #2 gets you a 10x-100x bigger speedup than #3. JavaScript fast, DOM slow.
  - crescentfresh 13y ago
    That article advocates instantiating a View per model object in direct opposition to the delegated approach. It acknowledges that there may be performance implications on large collections, just as the title post found. Are you sure that is the article you intended to reference?
    - byroot 13y ago
      The thing is, when you profile a typical backbone app, with a list of view. Most of the time (IIRC 60-70% for ~20 events) is spent registering DOM event handlers. Instantiating the view itself is nothing in comparison. So registering all the events on the container and delegating (in the POO meaning not DOM) give you a very good performance without scarifying too much your code complexity.
      - asolove 13y ago
        Yup, it's the DOM stuff and not the js initialization that is the bottleneck. This is why Ember and React can be faster: you still have the same number or more js objects, but the automatic event delegation and managed draw cycle minimize dom changes.

by asolove 13y ago

This is important to remember but hopefully not relevant. If you have event handlers on each card instead of delegating them to the container, that's a performance problem all by itself.

vonseel 13y ago

Can you clarify what you mean here? If I were writing a Backbone app, you mean I should bind to data attributes or similar instead of creating a new view for each item in a list?

asolove 13y ago
If you have a list of thousands of items, attaching event handlers to each of those items separately is relatively expensive, although it makes the view code nicer. If you are as serious about performance as these people, you would want to add delegated events on the parent level. There is a writeup about doing this in Backbone [1] although I can't vouch for it. In fairness, getting really good dom performance out of Backbone is hard because of the lack of built-in delegated event support and the non-synchronized redraws. If you have big apps that need to be super-fast, either read up on dom performance practices and adopt some helper libraries along with Backbone, or try a framework that has its own draw cycle and delegated event support. [1] http://lostechies.com/derickbailey/2011/10/11/backbone-js-getting-the-model-for-a-clicked-element/ http://lostechies.com/derickbailey/2011/10/11/backbone-js-ge...
- crescentfresh 13y ago
  > getting really good dom performance out of Backbone is hard because of the lack of built-in delegated event support It actually is builtin: https://github.com/jashkenas/backbone/blob/1.1.0/backbone.js#L1072 https://github.com/jashkenas/backbone/blob/1.1.0/backbone.js... In fact it takes a bit of effort to not use event delegation when setting up your events dict.
  - asolove 13y ago
    Well, Backbone handles delegation for elements within the same view. But it doesn't handle the case where you have lots of instances of the same view class in a list and want each handler registered only once for the whole list. You can do this manually by checking out the event target and maintaining a mapping from dom nodes to views, which you ought to do if you have lists of hundreds or thousands of repeated subviews. But Ember and various Backbone plugins can do this for you automatically.
    - crescentfresh 13y ago
      > it doesn't handle the case where you have lots of instances of the same view Wait I'm getting confused. Didn't the title post and your linked article both say not to do this if performance is the goal? (See "Tuesday" in OP). Isn't that what we're talking about here? Sorry if I misunderstood.
      - asolove 13y ago
        Yeah, I think this is just a terminology problem. Let's just lay out the complete answer: if you have a list of 1000 things to render in the same way, you can make it faster in various ways: 1. Don't render all of them at once, use pagination or infinite scroll. 2. Don't attach dom events to each item individually, instead attaching one event listener to the list container and having a way to go from the event's target to the appropriate view to act on. 3. Don't even create a view object for each item, just render them with the same template and have a composite view that knows how to act on each item's model for the delegated events. It's important to understand the relative performance benefits of these changes. #1 will make things faster in proportion to how much the page size is smaller the the full list size. #2 will reduce the number of DOM calls by a factor of the number of items in the list. #3 will reduce the number of JavaScript objects created. #2 gets you a 10x-100x bigger speedup than #3. JavaScript fast, DOM slow.
- crescentfresh 13y ago
  That article advocates instantiating a View per model object in direct opposition to the delegated approach. It acknowledges that there may be performance implications on large collections, just as the title post found. Are you sure that is the article you intended to reference?
  - byroot 13y ago
    The thing is, when you profile a typical backbone app, with a list of view. Most of the time (IIRC 60-70% for ~20 events) is spent registering DOM event handlers. Instantiating the view itself is nothing in comparison. So registering all the events on the container and delegating (in the POO meaning not DOM) give you a very good performance without scarifying too much your code complexity.
    - asolove 13y ago
      Yup, it's the DOM stuff and not the js initialization that is the bottleneck. This is why Ember and React can be faster: you still have the same number or more js objects, but the automatic event delegation and managed draw cycle minimize dom changes.