> Off load view rendering to the client to lower server costs.

Another way to lower server costs is to change tools. Eg, Phoenix renders HTML much more efficiently than Rails due to its use of IO lists.

http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io...

> User experience tends to be snappier since you aren't always waiting for the server to render your view.

The "Turbolinks" approach of only re-rendering the `<body>` also makes things feel snappy if the server response is fast.

https://changelog.com/ is a site that uses Phoenix + Turbolinks to achieve a snappy user experience with very little JS. The source is at https://github.com/thechangelog/changelog.com

Oh, interesting! Thanks for sharing. But there still is a little bit of server load, whereas front-end has 0.

Honestly, unless you're serving billions of pageviews on a very tight budget, I'm not really sure how much of a savings we're talking about here (server side vs. client side rendering).

> But there still is a little bit of server load, whereas front-end has 0.

That's true. OTOH, using a front-end framework has downsides, too. You have another framework involved, a big pile of JS that must be downloaded, more build tools, maybe you need to render server-side anyway for first page load...

> I'm not really sure how much of a savings we're talking about here (server side vs. client side rendering)

Yeah, me either. I think "what's the easiest way to get & maintain the desired user experience?" is probably the best question.

Well, Angular has a very heavy initialization penalty, enough that I know of a few companies that ditched it for React. I'll also add, as your front-end becomes more complex and uses a number of different libraries, the bundle becomes huge. There's ways around this of course, but some of pure JS stuff can get ugly quick.

Pretty badass. In addition to Turbolinks, there is also http://instantclick.io that has the benefit of prefetch which helps with perceived snappiness.