A diagram showing a client-side request, server response, with client-side processing

As mentioned in the previous article, one of the requirements of using on a page is that it must be on a server in order to work. This often confuses web developers who are only familiar with and : until this point, they have been able to store and view their web pages on almost any digital device. That is not true of pages that feature PHP.

In order to understand why, we need to look at the very basics of the internet. In particular, we must define two terms:

A client is, for our purposes, a device, or some software, that requests a resource on the internet. The client is often, but not exclusively, a web browser running on a computer. Other possible clients include internet-accessing software running on other devices such as smartphones, eMail programs, games, etc.

A server is software or a device that provides services in response to requests from clients. The possible services are many and varied:

  • Print servers forward documents from clients on a network to appropriate printers, controlling printer queues and priorities.
  • Game servers provide a single location for game clients to form teams, and communicate the moves, current positions, actions, and scores of players.
  • File servers store files in a centralized location so that everyone in an organization has equal access to resources.
  • Web servers store web pages and associated files (such as images), and provide those resources in response to client requests.

Servers are often specialized machines. If they consider them at all, most people probably think of servers as giant humming computers with blinking lights in a vast, cavern-like room. The reality is that almost any device with a processor can be turned into a server: what makes them special is the software, not the nature of the physical hardware that the server runs on. Obviously, computers with more memory, hard drive space, and processors tend to make better servers, as most are expected to respond to simultaneous requests from dozens to thousands of clients.

So in the traditional client-server model, a request for a web page could be shown as something like what you see at the top of this article.

Note that the only role for the server during this simple request is to provide the requested files: the HTML page, CSS, JavaScript code, and images. It does not process any of this material: it just finds it and hands it over. All the processing, or interpretation, is done by the client. That is, the web server does not “understand” HTML, CSS, or JavaScript: to the server, they are all just text files. It is your client that interprets the code in these files and displays the result.

A good analogy for the client-server relationship is that of a well-to-do Victorian household in the late 19th century. You, a London gentleman or woman, reside in the upper story of your home. The “help” – the servants and cooks – live downstairs. Being a very proper class-conscious Victorian, you don’t ever wish to be seen by the staff. Instead, all interaction with the help downstairs is made via a dumbwaiter: a small goods elevator in the wall that travels up and down between the floors. When you are hungry, you write requests for food on little slips of paper, sending them down in the dumbwaiter. The hired help reads the note, places food in the dumbwaiter, and sends it back upstairs to fulfill your request.

At the beginning of this arrangement, you have very primitive level of communication with your staff. If you ask for potatoes, the servants will simply put potatoes in the dumbwaiter and send them up to you – it’s up to you to do the peeling, mashing, and cooking. This means that your staff can respond very quickly to requests, but it places a good portion of the work of actually making food on you.

In the same way, all HTML, CSS and (in most cases) JavaScript code is requested from the server but is interpreted (i.e. run or executed) by the client. Historically, this is one of the reasons that Flash (another format that is primarily client-side) is not supported or blocked on modern mobile phones: the computing power needed to run complex Flash was beyond the capacity of the processors in the first smartphones.

As a basic request-response system, this works well. If you want more work done by your help staff (you send a request down for potatoes, and your cooks prepare potatoes au gratin in just the way you like) then the server must do more work. This means you (the client) gain prepared meals, but at the expense of working your servants harder. Obviously, if you have a dinner party, during which all of your guests order special meals, then your serving staff will have to work even harder. Too many requests and deliveries flying up and down the dumbwaiter run the risk of slowing down service.

In our case, why would you want to place more work on the server? Typically, server-side languages are used to create dynamic web pages: features on the page that alter under certain conditions. HTML (and to a certain degree, CSS) are stateless: they have no comprehension of the passing of time or (broadly speaking) the actions of a user on a web page. Some scenarios for using a server-side language such as PHP might include:

Combing both server-side and client-side processing, our diagram becomes:Client request, server response, with both client-side and server-side processing

Central to this model is the issue of balancing client-side processing with server-side demands. You will never be able to fully anticipate the power or abilities of web clients (they will always have different connection speeds, different browser versions and plugins, different processor speeds, etc). But placing too much work on servers starts to bog them down. Ideally, the two are balanced: some work is done by the client (interpreting HTML, CSS, JavaScript and images), and some by the server (PHP, ASP, and other server-side technologies), to create a seamless experience.

There are some other important reasons to use server-side technologies:

So long as the server is running and not overloaded with requests, server-side technologies always work. You don’t have to worry about browser type, available plugins, or platform: the server always remains the same, and PHP code always works.
Server-side code is inherently more secure than client-side, as the client never sees the server code, just as our Victorian gentleman never saw his servants: the server works to fulfill a client request, and sends the completed order. The client never sees the actual process of chopping, cooking, etc.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.