I tend to agree with you, but there are things that can/should run on both - validation of input for one. But I'd like to hear other things - I hear "use the same code on the server and client" all the time, but I haven't found a lot of use for that personally.

Turning a reactive web application into a regular "web site" -- ie. allowing you to use the bulk of the application without Javascript enabled. Great for SEO, too, at least until Google gets Javascript execution further along (which it's certainly doing, and getting better every day).

Another common example is something like a Markdown/BBCode parser.

The Meteor framework [1] uses this to good effect to support latency compensation.

You can optionally choose to include Meteor methods (ajax-style remote endpoints) on the client. Then when the method is called, the client-side version is run in addition to the real, server-side one being kicked off. If the server-side returns an error, such as due to insufficient permissions, the changes made client-side are rolled back. Combined with Meteor's client-side mongo implementation and reactive UI updates, it gives impressive "perceived performance" benefits.

1. https://www.meteor.com/

Aside from things like general libraries (e.g. serializing/deserializing data to/from the client), anything you want to happen client-side that you don't trust the client for, you will need to re-run on server side.

A simple one is validation of forms, but also doing rapid UI updates without having to do network round-trips.

template rendering

validation

routing

modular business logic e.g. - calculate total interest paid over the life of the loan provided the client pays x per month etc etc