I'm curious to see how this shared rendering between client/server plays out for non JS based frameworks such as Django, Rails, etc.
I've been feeling the burn myself—the desire to fully switch to handlebars templates in my Rails app. The expensive part would be building my API out more than I have, because I rely on associations in Rails view renders. However, gaining 1 template engine to rule front & back.
(OP here) Probably your best bet is to create a small Node web service that takes a template name and data and returns HTML. Then your (Rails, Python, PHP) app can call out to that in the request cycle.
Instagram.com does something similar; it's a Django app.
Seems to me that the approach with best separation of concerns would be to redirect the initials requests directly to node, which would then call the Python/Ruby/etc API to get the data to render the template. After that, the browser JS could call the API directly, and so the latter would never have to know about templates at all.
There's a different approach that performs all rendering server-side and sends snippets of HTML to the browser to be woven into the existing page. I suspect that would be more natural for non-JS frameworks.
I've been feeling the burn myself—the desire to fully switch to handlebars templates in my Rails app. The expensive part would be building my API out more than I have, because I rely on associations in Rails view renders. However, gaining 1 template engine to rule front & back.