As the guy who wrote the first bits of the Rdio code in question, it seems worth mentioning that the part in question has nothing to do with Backbone, or Ember, or anything else. That code is a cleanup function on an object that helps to abstract HTML5 <audio> vs our Flash fallback.
No matter what framework you are using, if you are solving the problems that we are solving, you are going to end up with that code.
Now, that said, I agree that learning all of the frameworks out there is advantageous, but you can't assume that the code in the blog post is indicative of anything having to do with Backbone or any other framework.
Is this entirely true? Clearly cleanup of event names like "loadedmetadata" is related to the audio element but '_bubbleProfilingEvent', '_logEvent', and general .unbind calls are on backbone-related objects, yeah?
The only backbone related code in that snippet is the .unbind() call and the .trigger call. This is needed because this is our wrapper around the media element; it is an event emitter. If you're going to make something emit custom events, you'll need code to emit them and clean them up when you're done.
One area where backbone is lacking is lifecycle management. You do sometimes have to unbind things in order to prevent leaks. Backbone is very minimal in this regard. At Rdio, we've built our own tools on top of Backbone to abstract lifecycle away from the developer as much as possible. That being said, that weakness isn't illustrated in the code example picked by the blog post.
Thanks for the comment. Before reading it, I admit to being lured into thinking the code in TFA was there to clean up after Backbone. Sneaky bit of writing...
No matter what framework you are using, if you are solving the problems that we are solving, you are going to end up with that code.
Now, that said, I agree that learning all of the frameworks out there is advantageous, but you can't assume that the code in the blog post is indicative of anything having to do with Backbone or any other framework.