Client-side logic OR Server-side logic?

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.

Answer 2

I tend to prefer server-side logic. My reasons are fairly simple:

1. I don't trust the client; this may or not be a true problem, but it's habitual
2. Server-side reduces the volume per transaction (though it does increase the number of transactions)
3. Server-side means that I can be fairly sure about what logic is taking place (I don't have to worry about the Javascript engine available to the client's browser)

There are probably more -and better- reasons, but these are the ones at the top of my mind right now. If I think of more I'll add them, or up-vote those that come up with them before I do.

---

Edited, valya comments that using client-side logic (using Ajax/JSON) allows for the (easier) creation of an API. This may well be true, but I can only half-agree (which is why I've not up-voted that answer yet).

My notion of server-side logic is to that which retrieves the data, and organises it; if I've got this right the logic is the 'controller' (C in MVC). And this is then passed to the 'view.' I tend to use the controller to get the data, and then the 'view' deals with presenting it to the user/client. So I don't see that client/server distinctions are necessarily relevant to the argument of creating an API, basically: horses for courses. :)

...also, as a hobbyist, I recognise that I may have a slightly twisted usage of MVC, so I'm willing to stand corrected on that point. But I still keep the presentation separate from the logic. And that separation is the plus point so far as APIs go.

Answer 3

I generally implement as much as reasonable client-side. The only exceptions that would make me go server-side would be to resolve the following:

Trust issues

Anyone is capable of debugging JavaScript and reading password's, etc. No-brainer here.

Performance issues

JavaScript engines are evolving fast so this is becoming less of an issue, but we're still in an IE-dominated world, so things will slow down when you deal with large sets of data.

Language issues

JavaScript is weakly-typed language and it makes a lot of assumptions of your code. This can cause you to employ spooky workarounds in order to get things working the way they should on certain browsers. I avoid this type of thing like the plague.

---

From your question, it sounds like you're simply trying to load values into a form. Barring any of the issues above, you have 3 options:

Pure client-side

The disadvantage is that your users' loading time would double (one load for the blank form, another load for the data). However, subsequent updates to the form would not require a refresh of the page. Users will like this if there will be a lot of data fetching from the server loading into the same form.

Pure server-side

The advantage is that your page would load with the data. However, subsequent updates to the data would require refreshes to all/significant portions of the page.

Server-client hybrid

You would have the best of both worlds, however you would need to create two data extraction points, causing your code to bloat slightly.

There are trade-offs with each option so you will have to weigh them and decide which one offers you the most benefit.