I agree that putting code in templates can lead to spaghetti. But the OP's proposed solution seems suboptimal because loosely coupling the template to the application code via "template animation" will lead to convoluted code with lots of hardcoded IDs on the application side, and brittleness on the template side because there's no way to see which IDs are used by the application.
A less extreme but more practical solution would be to disallow code in templates by making templates accept a data structure, like JSON, and giving them the bare minimum of capabilities to render it. So looping over an array is okay, checking for the existence of a property is okay, but querying the database from the template is impossible by construction. This way you also get language independence because many languages can generate JSON. Also, you can have compile time error detection (for both the template and the application code) if you use some sort of schema for the data structure, like Thrift or Protocol Buffers.
A less extreme but more practical solution would be to disallow code in templates by making templates accept a data structure, like JSON, and giving them the bare minimum of capabilities to render it. So looping over an array is okay, checking for the existence of a property is okay, but querying the database from the template is impossible by construction. This way you also get language independence because many languages can generate JSON. Also, you can have compile time error detection (for both the template and the application code) if you use some sort of schema for the data structure, like Thrift or Protocol Buffers.