My view - your business logic always lives on the server.

User-interface JavaScript running on the client should essentially be a slave to the server. Any decisions or calculations must be made on the server.

Building logic in JavaScript is tempting. It's often fast as no server roundtrip is involved. It is very easy to code as you're not having to worry about shipping values to and from the server.

However, when running on the client you have little control over faulty language implementations or, more likely, people manipulating your code and XHR payloads with tools such as Firebug. 

If the server blindly accepts what it is given by the client, you're in trouble. In Web 1.0 terms, this is synonymous with having a form with only JavaScript validation - a browser without JavaScript enabled would be able to submit invalid data.

Always running logic on the server has a host of advantages in addition to closing security holes. You are in control of the runtime and can reliably test its behaviour to be consistent. You only need to test your deployment runtime, not every browser you plan to support. From a performance point of view, the .NET or Java runtimes are likely to be considerably faster than JavaScript running on a client PC.

Some applications could run logic on both the client and server but this may result in duplication. Offloading processing to the browser could make an application more scalable. However, logic on the client should be considered supplemental and should only invested in where there is tangible benefit.