I've done this. I've done Angular. I've done Ajax calls to templates on the client side. I've done Knockout.

Give me client side data binding (2 way!) any day of the week vs sending the partial back from the server side. You invariably end up with a bunch of shitty glue code that's dealing with the actions AND the display.

Using a framework (Angular, Ember, KO, Backbone) all allow you to separate this spaghetti nightmare into manageable chunks.

In enterprise Java there are quite a bit of tools/frameworks designed to do this. While I don't particularly like the one they use at my company (bloated quirky IBM code-gen tool), it makes me see the merits of this approach (everything is basically a single page app & sections of the page are only replaced as necessary -- it is a Portal solution). Between that & seeing the JSF/PrimeFaces components my friend is always messing around with, I see the breakdown as 2 camps really -- People who like to write js vs. people who don't...

For the people who do, pushing data & logic into the client is fun, working with js, working on the actual "single-page app" & updating logic/css/html simultaneously.

For people who are more into static typing / web back-end, & don't particularly like the process of writing js, there is a nice movement toward dynamic pages where the updates are concocted through data-binding & behind-the-scenes ajax (generated by the component libs...). For a lot of enterprise Java devs, the dream of having an ultimate single source of domain logic in the Java layer somewhere lends itself well to this solution. You code typical OO paradigm and just try to integrate those models naturally into the front-end binding.

I like writing JS just fine (okay, maybe not as much as I like writing Scala). And I think that doing a good server-rendered experience would likely require something at least as sophisticated as Backbone. But I just think JS should be concerned mostly with managing client-side UI and continuity.

For the project I'm working on, pages are generally comprised of large blocks of content, and to the extent that there is SPA going on, it's mostly swapping these blocks. I can definitely see the advantage of client-side rendering when model data tends to be spread out across the whole page. But there's no reason one can't have their cake and eat it too.

This is basically what I do sometimes in Rails apps backing some light jQuery frontend. They are traditional web apps with a few pages doing many front end tasks (think about adding, editing, deleting entries in an address book). They are done by sending $.ajax calls to the server. Some of them get JSON responses but some of them just get HTML and replace the DOM of some elements. That HTML is rendered using the very same partials used to generate the page when it was loaded first (think about the <tr>s in that address book's <table>). This is DRY. Obviously having all the templates in the client would be also DRY but I don't want to have some templates in the client and some on the server. It's either all or nothing and, at least for me, it's just easier to do some of those things on the server.

Doing these things on the server also allows you to take advantage of server-side caching. For some applications, you cannot do this as they are too tightly tied to the current user. However, most applications have at least some sections that can be rendered and cached across user segments.

Does this require clients of your server to all support HTML so that they can screen-scrape partials to understand the results of their operations, or does your server support two output formats?

Two output formats is a reasonable solution, but one that you don't have to maintain if you go with a framework (such as Angular) that can render JSON back into HTML. It really boils down to whether you want to support a more complicated server or a more complicated client (or drop support for any clients that aren't yours).

It's a traditional web app, so it works with HTML. We don't plan to have anything else any time soon so the priority was on the time to have the HTML ready to go.

I did a Rails app serving JSON exactly one year ago, to a small Angular front end. It's was a little disheartening to see an empty page loading and then making JSON calls and thinking that by then a server rendered page would have been already fully loaded. That's why I said that it's all or nothing: either a single page app or many html pages. A few single app pages don't do well, unless they are preloaded with server rendered content.