This is not exactly correct. Many web applications are now foregoing client-side templating and are back to doing it on the server. GitHub is a great example of this, and Twitter is going this route too.
They had client side templating, and they switched back to server-side? Got any links for that, I'd love to read them (seriously, not snarkily).
Theres a counterpoint of linkedin moving towards client side with dust.js: http://engineering.linkedin.com/frontend/leaving-jsps-dust-m...
But I'm also interested in hearing about twitter/githubs change of heart.
That's a compromise I can get behind. And it's pretty much progressive enhancement...
Github/Twitter are massive with millions of visitors... they need to minimize every millisecond. It's not just about choosing the best developer-friendly or cleanest option.
Performance is #1.
That's not the case for the average smaller apps.
Frameworks like Backbone.js and Ember are growing very quicky and every open example app I've seen uses client-side templating.
They use Rails for pre-rendering the first page and some non-js pages like user settings & company info for what I can tell looking at their server responses.
1. Models on the client just aren't there yet. No relations, hacky one-off routing for sync. This is a big deal on more complicated apps where you want to represent multiple collections at once on a page and have nested resources. There are lots of other issues: sync timeouts, server validation failures, authorization, etc that you will have to write yourself. Also, then you are dealing with two different ORM which sucks.
2. i18n. This is basically unsupported on any of the client side frameworks I've seen. Even if it were, if you go partially client and part server rendering then where does your i18n live? You have to go all the way or not at all or deal with the mess.
3. SEO. If you care about SEO on the pages you are loading, you need to render on the server for the initial page load which is a PITA and redundant with client templates. Google is fixing this but their solution creates a different kind of mess.
Not such big issues:
1. Browser compatibility. This will fix itself in a year, or two?
2. Performance?? I guess it depends on how you measure performance and where. I think in general it is only the initial page load that is impacted and only the first time with caching. You still have to do a second request for the data itself I guess. Whatever. This is the least of my (and probably most people's) concerns.
The reality is, frameworks like Rails have built a lot of supporting features that are necessary and client frameworks like Backbone up to now just don't do everything they need to do. When they do, you'll still have SEO issues.
All these problems can and will be resolved one day. I especially look forward to being able to use the exact same models/relations/templates on both the sever and client which hopefully is where some combo of express/node/jade + some client widget library.
Keep i18n strings and templates as JSON or some other format that can be easily parsed by both the client and the server, one for each language. Have both your client and server code use the file corresponding to the user's locale.
Could this be easier with better i18n support in today's client-side and server-side frameworks? Most definitely. Is it really that messy? I don't think so.
(And yes, I'm aware that not all i18n can be expressed as simple string templates, but those are corner cases that don't add THAT much complexity to the system.)