Pros/cons between emphasizing client-side or server-side processing

Question

Why would I want to write a web app with lots of processing server-side?

To me, writing the program client-side is a huge advantage because it takes away as much server load as possible because it only has to send data to the client with minimal processing.

I see very little on writing web-apps besides writing it server-side and treating client-side as only a view. Why would I ever want to do this? The only advantage I see is that I can write in whatever language I want (http://www.paulgraham.com/avg.html).

Answer 1

There are two major issues.

1. The first is easy--you usually don't know what sort of resources are available on the client side. If it requires 1.5GB to process something, can you really push that onto an unknown client browser (IE, Safari, Opera, Firefox, etc.) on an unknown client platform? Will the client appreciate his system dogging when you overwhelm it?

2. The second is more architectural--what layers do you want to expose to the outside world? Most would agree that it's incredibly risky to expose your data layer. How about your service layer? Do you really want to deliver that logic out there? If you do, are you also exposing the entry points to your data layer? If you keep the service layer server side, then what's left? The UI, right? See reason 1 about for considerations on how much of that lives on the server and how much on the client.

Answer 2

First and foremost is Security. Push all your logic out to the client and it is fair game for hackers and exploits.

Anything with any perceived value won't last 5 minutes, especially monetary value, and will be gamed or hacked or exploited and break your system pretty badly. Even if it has little to no monetary value, there is a class of people that will hack it just to break your system because they are bored.

Answer 3

Client Side Versus Server Side

Client side processing is in line with the more popular REST standards as well as MVC as opposed to page based approaches and SOAP. The emergence of these trends and focus on AJAX and Html-RIA, client side scripting is on the rise and more popular; however, due to security concerns and client capability, client-side scripting has a particular niche and should not be used for everything.

Considerations:

Mobile

If a large segment of your target audience will be mobile users, heavy processing should be left up to the server.

Cross-browser consistency

Web standards have come a long way and this may not be as much of a concern, but every web developer knows that IE 6,7, and 8 and sometimes Safari can act funny on the client side--certain functions may not run because of security restrictions and others because of un-implemented standards. It's also important to note that the end user can configure a browser to have certain restrictions or even completely turn client-side processing off (no javascript!). If consistency is a requirement for 100% of users (and especially if you're doing something unorthodox) server side is most important.

Security

Any data manipulation that you want to secure needs to be done on the server. Any data that is processed on the client side is absolutely open for manipulation. For example, if you have a javascript function that processes some information that then gets posted back into the system--it would be very easy to manipulate the result just before it is posted back even if you have exemplary back-end security

UI/UX

Client-side processing is left for the user interface and creating rich internet applications (RIAs). It is used to create animations, effects, user interactions, as well as dynamically loading content through AJAX calls instead of re-loading a whole page.

Answer 4

Primarily it will be a duplication of effort. Most likely any data from the client will have be checked and processed at the server level again.

The server cannot assume that your rich/robust client sent the data, so with anything data being sent, the server must validate it and process. So it makes sense to put it there.

However, I beleive some logic can be done at the client level for a better UI experience.

You are correct, why send data to the server if is not complete or incorrect. It's easy to check for required fields or for properly formatted phones or email addresses. I never liked submitting a form and then waiting 5 seconds to tell me I forgot to enter a field. That kind of processing, sure, do it on the client and make sure it is correct and using client side logic for a fast response to the user. As you have pointed out, a bonus side effect would be that your server would have to deal with less bad data requests. BUT, the server still has to validate also, so you are duping logic. But, your users will be happier.

There is a fine line here. Simple validation logic OK, core business logic not OK.

Answer 5

1. First of all you need to understand the architecture of web applications, most if not all are 3-tier:

   a) Client/Presentation - HTML and Javascript, may contain ActiveX/Flash/Java Applets/Silverlight. I will go out on a limb and add native mobile applications which communicate with a backend server. Basically the role of this layer is to provide an interface for the user of the system to interact with it.

   b) Business Logic - PHP/RoR/Java where the data from the client is collected, processed and store and where client requests for data are processed and sent back to the client

   c) Backend Data Store - provides persistent storage for the system information

2. So where do you do the validation, in all layers. Why?

   a) Client side - ensure the user enters correct data, required fields etc

   b) Business logic - filter, sanitize and validate client data. Run more complex business rules to ensure that the data is well formed for storage. Some of the validation done at the front end is repeated here, due to the fact that there may be different clients, take for example browsers the Javascript can be disabled. It may also accept data from different sources via APIs for example, so it all needs to be validated.

   c) Backend Data Store - constraints ensure that the data is well formed for storage and later retrieval.

So where do you focus your validation efforts, use each layer to perform the validation that suits it best, and leave more complex rules for the layer that can handle it

Answer 6

A big part is keeping your processing close to your data. If you've got hundreds of GB of data you're obviously not going to ship that to a client. With data access speeds increasing this is becoming less of an issue, but if you've got a Big Data site you still want to do as much filtering and narrowing on the server as you can before shipping it out.

Answer 7

When you create your behavior completely on the client side (say, with Javascript), SEO can become a problem.

Websolutions that keep a lot on the server side are more easily able to keep specific content posted on a specific URL (usually RESTful), in a way that is visible to search engines.

This also means a visitor can bookmark a specific page. Have you tried that on Facebook?

This stuff can be solved, but it is usually built into applications that do a lot on the server (RAILS, WordPress etc), whereas if you're building in say REACT, you will have to jump through hoops.

Answer 8

The reason is stability.

On server side, I can choose stable components. Usually this means I choose Java and a bunch of very carefully selected libraries such as FreeMarker. Needless to say, every library apart from Java's standard libraries is treated as disposable, so I access the external libraries through a self-made wrapper. This means I can change easily from one library to another if the requirement arises.

Whenever I update Java to a new version, it usually works well because Java is an extremely stable component even across major version updates. And also, every server I have is running the same Java version. Not every client is running the same JavaScript implementation.

On client side, I cannot choose stable components. The browser makers will force me to choose JavaScript, a language that I particularly don't like, but one that I am forced to use. (And don't tell me about languages that are compiled to JavaScript, they are horrible!) The JavaScript implementation of every browser is different. This means it is a total hell to test my product with every supported browser version.

My solution? I perform as much processing as I can on the server side, and the client side is only a lightweight wrapper that sends data to the server and receives data from the server in the form of JSON and HTML fragments. Avoid XML; use JSON instead.

I don't do client-side templating; I render the content on the server to a HTML fragment that I then assign using the .innerHTML attribute to various placeholder elements on the client side. This keep the technology stack as simple as possible, because I don't need two template engines (a Java one and a JavaScript one).

The drawback is obviously speed-of-light latency; half a second of latency isn't uncommon between continents.

Do consider that your clients these days may be smartphones. Smartphones have a limited battery life, so if you're doing heavy computation, better to offload it to your servers. However, simple things can be more energy-efficient when done on the client side because then you can avoid radio access. But the main argument, stability, may mean it actually may make sense to offload even simple computation to the server.

As an addendum, as already observed in some answers, you gain security as well. If application logic is entirely on the client side, somebody can e.g. set a price to whatever thing they are going to purchase from your online web shop.