Q:

Backbone.js best practice for event handlers naming

Let's say I have a function in a view that triggers when some kind of state is changed.
What would be best to name it and why?

stateChange
stateChanged
onStateChange
onStateChanged

A:

I'm personally perefer to use onEventName names keeping native naming convention for DOM event handlers.
Like myElement.onclick = function() { /* ... */ } for click event.
So for myEvent I'm using handler named onMyEvent.
And if I have event stateChange, then I'll use onStateChange handler.
But really this question is more specific for each team of developers and code-style conventions inside the team/company.
So the main goal in such kind of questions is to keep the code style same in all parts to ensure readability.
Therefore if you're working in a team, just keep sticky to team's code writing conventions and if you're working alone on existing code, try to keep its code-style (sure if that style is not obviously ugly).
UPDATE: Understanding.
What is the event? Roughly it's an action initiated outside or inside the program, in other words something happens in system, e.g. some state changes (the state of keyboard, of mouse, of I/O devices, etc.) doesn't matter how (the user clicked on mouse or some program sent the mouse click signal to system).
Say the browser window is subscribed to get a notifications about some events and the operating system sending them to it as soon as possible, we'll assume that at same time when something happens. So if user clicks his mouse when the browser window is active and the document has a focus, browser says to document to fire the click event. And here our onclick handler starting its invocation. In other words the system says us that now happens a change of some state. And we're handling this change and not are handling a fact saying us that state has been changed.
Let's assume that our handler named as onClicked. Since the handler's name saying in past tense we can get a reasonable question: "When clicked, how long ago it happened? How many times it was clicked? Hmm, maybe it's too late to handle this action (or actions?) at all...". So this name tells us that something happened sometime in past.
In contrast when our handler named as onClick it's obviously that click event just fired and fired once and we was notified about it immediately. And we're going to handle the click event - the information saying us that the state of mouse changed right now (not mouse clicked, but the event of click).
So the names in past tense are more appropriate for the cases when we need to check if some state has been changed or not. E.g. if the variable stores the state = 1 we can call the function isStateChanged(); which will compare the value in state variable with the real value at the current moment. And here the past tense is good choice for naming.

A:

onStateChanged because this function triggers whenever some kind of state is changed.

A:

I Googled a few names and noted the number of results returned. You can get some indication of the relative popularity of the most common forms for event handlers:
stateChanged 168k
stateChange 81k [1] 
handleStateChange 61k
onStateChange 59k 
onStateChanged 12k 
beforeStateChange 2k

[1] Results show stateChange used mostly as the name of an event, not a handler.
Using different event types gives a much stronger recommendation towards the onStateChange form:
change [2]
onChange 2000k
onChanged 85k
handleChange 36k
beforeChange 27k
afterChange 22k

click [2]
onClick 48000k
onClicked 58k
handleClick 50k
beforeClick 8k [3]

onDrag 100k
handleDrag 36k
beforeDrag 32k
afterDrag 4k
onDragged 5k

[2] Too many results unrelated to programming.
[3] Apparently certain Microsoft API's can anticipate when the user is going to click.

