For the record, the approach that we use to serve templates (along with CSS, and JavaScript), is available here:

http://documentcloud.github.com/jammit/

Just the templating bit: http://documentcloud.github.com/jammit/#jst

... which allows us to include all of our templates in our JavaScript asset packages by listing them like this:

https://github.com/documentcloud/documentcloud/blob/master/c...

... which then means that they'll be served as part of the final, minified, compressed "core" asset package here:

http://www.documentcloud.org/assets/core.js (bottom of the file)

Or, as a standalone asset here:

http://www.documentcloud.org/assets/core.jst

I was commenting hoping to get others to explain their templating system, honored to see your reply :)

This is what we use: https://github.com/teambox/trimmer

In a nutshell, it takes everything under app/templates and compiles it from Rails (so it has access to I18n and ruby) and serves jades, which we later compile and minify.

Trimmer serves the Template and I18n objects, as you can see on this compiled file:

https://d238xsvyykqg39.cloudfront.net/assets/trimmer-en-58fc...

I like that your solution actually packs it together with the rest of the code, avoiding one extra request for templates. Maybe we'll add that to our system too.

This might not be possible for you, but we're running under nodejs and using stitch[1]. It compiles the templates to javascript functions, and we bundle them with all the rest of the javascript as one big file. Simple distribution and awesome performance.

[1] https://github.com/sstephenson/stitch

What I do is Makefile compiling templates to separate js files for development and for production I combine them using the module system which makes sense - in different projects I had stitch, ender.js and AMD (require.js & seajs).