I was noticing the other day that I have some messy fucking templates in code I stepped away from and have recently come back to. This is the result of trying to put all the logic for the HTML produced in the templates, which initially seems like it is a good thing. And it is, for some situations. But consider the case of the element that needs to have an attribute changed depending on the value of some property on the data object, e.g.:
{#if ($T.StupidProperty)}
<input type="checkbox" id="stupidCheckbox" disabled="true"/>
{#else}
<input type="checkbox" id="stupidCheckbox"/>
{#/if}
You can question my syntax, but I feel confident in saying that there are a lot of different ways to write that and they are all, 100%, across the board, ugly. For some things, like elements that should be hidden from users who don't have administrative rights, or actions that aren't available after a certain point, this is great and makes sense (but is still ugly). In my application, though, there are a tremendous number of things that get shown and hidden and enabled and disabled dynamically. And there are event handlers in place to manage all that already. After stepping away from this code and then coming back to it, I noticed there was a lot of duplicate logic and a much tidier way to manage it all.
The init function for this application is already a beast and abstracting out the logic in the event handlers and adding calls in the init is most certainly not going to make it any more charming. Worse, it's going to detract from the self-documenting nature of the templates as they are now. Instead of being able to look at the template and see very clearly how a certain data property may get applied, any future developer will have to track down the form element defining the property and all its listeners. (Thankfully, this will be no big deal if I take the time to deal with documentation in a less half-assed way.)
Those aren't the reasons I did this in the first place, though. I was thinking about templates in terms of what they'd do if they were server-parsed files rendering only HTML. In this instance I am not running JS on the server, the server doesn't know these template files from a jpeg of my cat, and that is damned stupid. The templates are Javascript and the event handlers that will eventually turn things on and off dynamically are Javascript. Javascript was put here to serve us. It was not put here to dictate that we keep our templates neatly divorced from our event handlers and that our templates must load the HTML's correct state in full when we process the template.
I think it's tricky to say that templates should not be managing state. If you have a situation where the same template might be server-rendered, they most likely should be. Likewise, if all the state changes can be handled with CSS, there's a better argument for adding the data properties as classes on a container element à la Modernizr. Where those are not the case and some handler will manage the same state once the user begins to interact with the page, however, that logic shouldn't be in the template.