Once upon a time I wrote a post espousing the benefits of server-side rendering over client-side rendering. I've long meant to revisit the topic. However, my goal with this redux isn't to readdress the original, but rather talk more broadly about the balance with respect to client and server side code; specifically with respect to client-side MVC frameworks (angular, ember, ...)
Since writing the original, my opinion hasn't swayed by any appreciable amount. But I have observed the building of three significant systems, each containing a significant front-end component. One of these systems was traditional RoR website, while two used client-side MVC frameworks ("MVC" from hereon in, since I won't be talking about server-side). In each case, the wrong technology choice was made and the consequences were as gruesome as they were obvious and as obvious as they were predictable.
The problem with MVC isn't a problem with MVC, but rather how developers are using it. They aren't using it with laser-like precision to enhance specific interactions and flows, but are carpet bombing their own systems. Which isn't to say there aren't valid cases for a comprehensive MVC powered sites, but those are the exception (maybe something like Asana or Gmail?)
The two systems which I've seen rely on MVC (remember, I'm using MVC to mean client-side MVC) were both internal-facing CMS'. The problem here is that most CMS' are meant to focus on data integrity and correctness. State changes need to propagate, workflows need to guide and business logic must be enforced. This can be pretty complex stuff and it tends to require a intimate knowledge of the business and how it links to the data. The idea of putting anything but the most trivial validation on the client should set off alarms in your head and in your organization. There's a clear security concern, there's a performance concern (CMS' tend to interact with the DB and other internal tools which is much better to do in a single request), but worse is the duplication and poor cohesiveness. Given that we need to duplicate simple validation rules, it should be obvious that much of the more complex logic must also be duplicated. Also, as much as MVC is built around the separation of model and views, the cleanliness of that separation is nothing compared to the barrier between client and server running code.
In both cases, the result was data incorrectness, superficial business logic, unhelpful workflows, poor maintainability, lack of testing, and complicated user interfaces. Undoubtedly, some of the problems were implementation specific. All of those issues could surface within a more traditionally-built site. But I insist that it would require significantly worse programmers to mess it up at the same scale.
Furthermore, this isn't to say that MVC can't be leveraged within a CMS, but only where it makes sense. And it doesn't make sense when it comes to providing a paged and filterable list of users which can be edited. That should be obvious.
A simplification, no doubt, but swapping out a container's innerHTML through AJAX is powerful and simple. Use it. (there are modern client and server-side tools and frameworks that can help).
When I started a new job in 2006, I was made responsible for the backend of two separate internal dashboards. Their frontends were built in Flash. They were failures. Eight years from now, I'll be able to say the identical things about 2 systems that I saw in 2013.