Something I find really vexing is dealing with lots of very small pieces of HTML. I'm talking about something on the order of:
<a href="/FollowUser?id=438497" class="follow unfollowed">Follow Jane Doe!</a>
Having all the little bits of HTML in one constants file - possibly shared with error messages and other strings, possibly not - seems very natural to me. But it means a template can't be managed in the same way by the client and the server. You could have the same sort of constants file on the server, and have the server use its constant strings to populate the JS version, but that might be tricky, depending on how the server's set up. Where I think this makes the most sense is for client-only enhancements, things the client will need frequently that will replace less dynamic markup initially supplied by the server.2. A file for every snippet
Good lord, I hate this. I hate it so much. I mean, I love it when the template in question is not a snippet but some big-ass piece of markup with lots of logic and lots of properties displayed and, in general, something meaty enough to warrant its own file. But for a single damned link? Uh-uh. That's ugly. However.. it works. It allows the client and the server to retrieve and parse the template with neither needing any special handling or intervention from the other. But it means that on the client, each tiny template is an additional request. Really, what bugs me is having all those files sitting around. I loathe the idea of having one file per type of repeated link. Again, though, it gets the job done.3. Snippets with the files that use them
This is another client-only approach, but one that seems more elegant. Instead of keeping all the snippets in one big file, you could keep relevant snippets at the top of the files containing the scripts that need them. For something like a widget, that works beautifully. In the case of something like a follow link or avatar thumbnail that belongs to no single script, however, it means the code is either going to be repeated or will end up in something equivalent to the big-ass constants file. For plugins and things it seems sexy as hell.4. Strings that live on the server
Even though strings of HTML on the server are just strings, not HTML, I find this uncomfortable. I like HTML to be in some file whose file extension makes it immediately clear it's going to end up on the client. Putting strings in a C# or PHP file or something is very tidy, but it separates pieces of HTML from their larger HTML families, which makes them more difficult to find and less natural to manage. If you did do something like this, it seems like you'd probably render those snippets for client use within script blocks on the pages themselves. Once you do that, you're no longer in a position to lazy-load the templates. They're either in the page or they aren't. This is awesome for follow links and avatar thumbnails, but sucks for small snippets used by plugins that the user may never need.
Really these aren't four separate approaches, but four ways of combining various things. Which makes it all the more confusing. Do you work with templates frequently, and do you use templates for very short, relatively dumb bits of HTML? How do you do it?