2) If you are adding/removing individual DOM nodes as suggested in #1 then you aren't using live binding, so you would need to implement the sorting yourself. Usually we sorted a list of items into the proper order and then rendered them using a loop. If the order changed, we re-rendered. 

3) It is possible, but it's not something handled by CanJS out of the box. You would have to write your own logic to do this sort of ordering. In the end, I'm sure just sorting the list of model instances and re-rendering the whole list is faster. DOM manipulation is the most expensive thing you can do and if you have a sorting algorithm that is constantly shifting DOM elements around, you are going to see bigger performance problems than just re-rendering.

I shared some code that uses Array.sort on a Model.List in this thread. It uses live binding to keep a list of items sorted, which may be quicker than sorting DOM elements that are already rendered.

As I see, you can "live bind" the item attributes

1. <%= car.attr('name') %>

and only that will get re-rendered when the item is changed, not the whole list. Why can't it be so with the list items (elements)? I really disagree that the performance is bad when you have to add a single (!) newly created element. I don't believe that it's faster to re-render all, let's say 1000 element, list.

Ok, I'm not going to test this right now because it's midnight, but I think that I may be right.

Here are benchmarks about the DOM vs innerHTML: http://jsperf.com/dom-vs-innerhtml/10  DOM wins for Chrome and Safari, but innerHTML wins for Firefox.

Just think about it -  you have a 1000 items in the list and you crate a new one... Let's say that appending to the list takes twice as much (and it depends on the browser, this time for Firefox) than using innerHTML. What's faster - to append single element to the list or rebuild 1000 items by using innerHTML? Math is simple here.

I don't understand the functionality (live binding) here, because I haven't red all the code, but, please, try to figure this out, because I believe that it is better.

Isn't the canJS setting a references to the elements? An example how I have done something like that with jQuery:

There are many frameworks out there, I find the canJS simplest, because I can use it as a jQuery extension (or vice-verse) and I don't have to compile anything. I just disagree that this thing can't be done.

Here's how live binding works:

Anytime you use attr(), all the code between the magic tags is wrapped in a function and will be re-run every time the attribute you used is updated.

In the case of the .each, the entire loop is wrapped in a function and called every time the length of the list is changed.

Nothing is stopping you from appending and removing items from the DOM yourself when they are created/deleted. And you're welcome to fork CanJS and attempt to implement this sort of handling of live binding. Let us know how things go.

Basically you can use it like this:

It removes and adds only the affected elements and does some neat things like showing a loading text when you pass a Deferred to the list.

It does not handle sorting though. I agree with Curtis though, re-rendering is probably faster (especially since this list Control only requires one DOM access to insert the list).