If your template is of a single element, then you can use .Elt() instead of .Doc(). This will return a value of type Elt (which is a subtype of Doc) which has a property .Html returning a string. Note however, as Adam said, that this will not include any dynamic behavior (events, bound Vars, etc) you might have included in your template instantiation.

I believe we don't have an API for this for client-side use yet. It's worth remembering that instantiated templates are not just HTML, they also potentially come with embedded dynamic behavior (pagelets, event handlers, etc.) - and serializing them to markup requires handling of "managed placeholders" (scripts, meta, and styles) to include/reference generated client-side artifacts/code (think of a Google map control placed inside body in your snippet.) This is done automatically when serving sitelet pages, i.e. on the server, seamlessly. However, if you need equivalent functionality on the client, you have to take care of these details yourself.

One obvious approach is to use the same server-side mechanism to return the computed HTML to the client, having it exposed on a sitelet endpoint and fetching it from the client via an HTTP request. This, however, incurs the obvious penalty of a server roundtrip.

You should also be aware of the two main working modes for client-side templates, documented under the Optional parameters/clientLoad section on the UI.Next Templating documentation page. This means that your template is available on the client either in a JS-inlined form or directly in the DOM, and each operation on it will accumulate DOM nodes in memory. So surely, these can be read by hooking into the client-side templating internals.

@tarmil - Any ideas about exposing some kind of an API over client-side templates?