[rudasn]

> It makes writing a view with subviews very easy. You simply use the Handlebars helper exactly where you want that view and the rest is taken care of for you.

It does indeed look very simple and easy but what I would be concerned about is that you have logic in your views that perhaps shouldn't be there. Your views are now dependent on the template language/parser you are using. Have you tried any other approaches that didn't work so well/easy before coming to this solution?

> If a view can only work in a particular situation (eg: nested inside a list which handles its events), then that creates hard dependencies between those two views and you can quickly get into a mess.

Agree. But how about having per view instance dependency instead of per view constructor. For example,

    <div class="listenNetwork__creator">
        {{view "views/user/user-badge" resource_id=user.id parent_view=this }}
    </div>

So your user-badge view can bind its events on the parent_view.el (if available), otherwise on itself. Backbone does this in a way on its delegateEvents method. If there is no selector specified in your event it uses bind on this.$el, otherwise it uses this.$el.delegate.

Thanks

[nickfisher]

That's not a bad idea actually -- I might look into that. With only one subview, it ends up with the same amount of handlers, so the benefit would only be seen in list-like views with repeated subviews, right?

[rudasn]

Exactly, like when you are rendering a list of (sounds|users|comments|whatever).