5 ways to not write html in your backend code

At work right now I'm involved in a minor turf war over HTML. I write it in the .aspx and then other people sometimes move it into the C#, which aggravates me. The reason given for this is Don't Repeat Yourself, but I'm trying to make the case that there are other ways to respect DRY in this situation. I can think of at least five methods that would be both more maintainable and less code the server needs to interpret.

I admit it's not the cleanest thing to do, but adding boolean properties on the objects being rendered that say things like whether a user is the same one who's logged in or whether some object has an image attached to it offers a lot of flexibility on the UI. It's a simple way to get around writing backend logic in the page itself while offering the possibility of later reuse. It's messy, though, because there's a temptation to just misuse existing properties instead of asking for a new property, and conversely, you can end up with a lot of duplicate information. A good example is the length of an array. You could end up repeatedly asking the array for its size to render things differently for 0 objects or some minimum number of objects that you want users to be able to page through. You could get this information instead in properties like hasObjects and doPaging or something, but that's just adding to an API things you could infer from what you have already. And neither alleviates the need for backend loops and conditionals mixed in with your HTML.

Forgive me for not knowing how this concept works in other frameworks, but I'm guessing they all natively have something similar or can be abused into offering it. Instead of adding helper properties to your API, you could create those properties based on a single object passed into a control. This is less flexible than having the extra properties available to everything on the page, but it feels much cleaner and object oriented. In .NET MVC, there seems to be a movement against having code behinds for anything, which I think is unfortunate, since creating helpers for use within the context of a specific user control based on one large, self-contained object makes much more sense from an MVC perspective than having the server try to figure out beforehand everything the page will need.

This is not a solution that works for all situations, obviously, since it requires Javascript. However, if you've got a client-based application that just has to have Javascript anyway, it works very well. I know this is not a popular approach with some people because of the extra rendering time when the page/application first loads and you have to parse and insert your data only after that happens, instead of doing it all beforehand. But if we're assuming this is a client-based application, we can also assume it runs on AJAX and you're only going to be loading the page once. So sometimes the tradeoff seems acceptable.

Since I haven't actually played with this technology, I will sound like a dumbass if I try to go into why this would be good and therefore I won't. But from what I think I understand of it, it would fix the problems in the method above (reliance on Javascript, needing to parse everything when the page first loads). I take the proposal to include templates in jQuery as a sign that, if templates don't already work with these server side JS technologies, they soon will. If I'm correct about not needing duplicate files, it seems like it could be really easy and fly as hell.

This is my favorite. When the page first renders, you pass an object from the server side into the control, it plugs in the values, and all the HTML is rendered and ready when the client downloads it. Say there's an existing list of Things, and the user adds a new Thing. The markup from the same user control that rendered the other Things has been added to the page inside a script tag (or a convenient external URL) and now, when the server responds with the confirmed data about the newly added Thing, it's applied to the template and that gets rendered without refreshing the page. I think that's fucking elegant. My boss thinks I'm high and that we should put the markup in user controls and use those both the first time the page renders and to respond to XHRs with the markup pre-populated.

If you're reading this, what do you think? Am I betting on the wrong horse here? Did I miss something?