[stingraycharles]

What I never understood is why they embrace rendering templates at the server. Is it simply a matter of "because we can and it's nice for the people that want to use it", or is there a real real reason why pushing raw HTML via AJAX request is better?

I always thought the status quo in the web development world was to use a framework like Backbone.JS to communicate with your backend and use a client-side template engine to render the templates.

[nostromo]

We push HTML through AJAX to keep all of our templating centralized and consistent.

For a while we used templates for the container page, and then backbone and js templating for certain elements on the page. It can become the 2013 equivalent of spaghetti code if you're not careful.

Now, with HTML via AJAX, you have a clear separation of concerns. For example: the designer doesn't need a dev to make an HTML change, and the dev knows that there will be one place that controls how pages are rendered.

[SkyMarshal]

Definitely not status quo. One big example is when Twitter moved away from that back to server side rendering for performance reasons [1].

There are basically three aspects of website performance - server performance, network performance, and client performance. You can control server performance and network latency (CDN), but you can't control what's going on on your users computers.

For example, if they're tab-abusers (guilty as charged) with 50+ non-trivial tabs open, plus other apps open and stuff running in the background, then your beautiful high-performance UI could start chugging (as many do on my abused laptop).

So you really have to think about what your main userbase will be and whether you need to put the rendering chunk of your app's CPU usage on your own servers or on your client's desktops/laptops/tablets/phones.

[1]: https://blog.twitter.com/2012/improving-performance-twitterc...

- http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-R...

[nek4life]

If you have an application that doesn't need to be indexed by search engines, yes. If you have a content heavy website the preferable method is still to render templates on the server. It still varies depending on your use case. I wouldn't say that is the status quo at all.

[saryant]

We use the templates to render email messages on the server primarily.

Note that Play doesn't force you to use the templates, you can plug in your own very easily or forgo them entirely and just push JSON out for client-side rendering.

We use that for monitoring our backend Akka cluster: Play streams JSON using server-sent events to the client for rendering Mustache.js templates.

I don't know the exact motivation for including compiled templates (we love them) but in practice Play is perfectly happy either way.

[virtualwhys]

I don't know, maybe type safety?

Don't forget about Play's truly excellent form generation/validation, and yes, raw speed of jvm byte code.

Rails truly (DHH) made a blog post on why they switched to generating html server-side: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...

[kev009]

It's optional; nothing forces you to use them vs doing the AJAX du jour.

Play templates are particularly speedy though, they get compiled into JVM bytecode. I actually prefer doing things that way and keeping markup and JS to a minimum. It 'feels' faster and more robust to me.