Question

I’ve done some web-based projects, and most of the difficulties I’ve met with (questions, confusions) could be figured out with help. But I still have an important question, even after asking some experienced developers: When functionality can be implemented with both server-side code and client-side scripting (JavaScript), which one should be preferred?

A simple example:

To render a dynamic html page, I can format the page in server-side code (PHP, python) and use Ajax to fetch the formatted page and render it directly (more logic on server-side, less on client-side).

I can also use Ajax to fetch the data (not formatted, JSON) and use client-side scripting to format the page and render it with more processing (the server gets the data from a DB or other source, and returns it to the client with JSON or XML. More logic on client-side and less on server).

So how can I decide which one is better? Which one offers better performance? Why? Which one is more user-friendly?

With browsers’ JS engines evolving, JS can be interpreted in less time, so should I prefer client-side scripting?

On the other hand, with hardware evolving, server performance is growing and the cost of sever-side logic will decrease, so should I prefer server-side scripting?

EDIT:

With the answers, I want to give a brief summary.

Pros of client-side logic:

1. Better user experience (faster).
2. Less network bandwidth (lower cost).
3. Increased scalability (reduced server load).

Pros of server-side logic:

1. Security issues.
2. Better availability and accessibility (mobile devices and old browsers).
3. Better SEO.
4. Easily expandable (can add more servers, but can’t make the browser faster).

It seems that we need to balance these two approaches when facing a specific scenario. But how? What’s the best practice?

I will use client-side logic except in the following conditions:

1. Security critical.
2. Special groups (JavaScript disabled, mobile devices, and others).

Answer 1

In many cases, I’m afraid the best answer is both.

As Ricebowl stated, never trust the client. However, I feel that it’s almost always a problem if you do trust the client. If your application is worth writing, it’s worth properly securing. If anyone can break it by writing their own client and passing data you don’t expect, that’s a bad thing. For that reason, you need to validate on the server.

Unfortunately if you validate everything on the server, that often leaves the user with a poor user experience. They may fill out a form only to find that a number of things they entered are incorrect. This may have worked for “Internet 1.0”, but people’s expectations are higher on today’s Internet.

This potentially leaves you writing quite a bit of redundant code, and maintaining it in two or more places (some of the definitions such as maximum lengths also need to be maintained in the data tier). For reasonably large applications, I tend to solve this issue using code generation. Personally I use a UML modeling tool (Sparx System’s Enterprise Architect) to model the “input rules” of the system, then make use of partial classes (I’m usually working in .NET) to code generate the validation logic. You can achieve a similar thing by coding your rules in a format such as XML and deriving a number of checks from that XML file (input length, input mask, etc.) on both the client and server tier.

Probably not what you wanted to hear, but if you want to do it right, you need to enforce rules on both tiers.