Client-Server workloads on the Web - Everyone is doing it wrong
The way we handle client-server architecture in the modern web is completely backwards from how it should be. According to the Encyclopedia Britannica's description on the subject, a computer user tells the client computer to send a request to the server which should then return the results of the request to the client in order to be displayed to the user. This is entirely the opposite of how we handle things on the web, which is built upon the client-server architecture.
A good way to illustrate how client-server architecture is implemented entirely backwards on the web is this; Let's say that you and a few friends want to go to a fancy restaurant to have a good time and good experience. So you get in your car and drive to the restaurant (which from this point on will be referred to as "yummi food." yes that is "yummi" with an "i") in order to meet up with your friends and have the aforementioned good experience that you have been dreaming about ever since you got in your car. You arrive at "yummi food" and meet up with your friends, after which you proceed to enter the establishment. You and your group are observing appropriate etiquette for such a prestigious dining establishment, but something seems off.
For instance, instead of your server extending the courtesy of pulling the chairs out from the table for you and your friends (the clients), you are directed to seat yourself at your reserved table. It may not seem like a big deal to you at the time, but what comes next is truly perplexing. After your group has seated themselves, the server comes to your table to take your orders, one-by-one the server writes down everyone's orders until the last person in your group has ordered their food. You then wait, as you would expect, for the food to be prepared, however, rather quickly, the server comes back, not with your food, but a recipe and a list of precise instructions for how to cook and prepare the food, along with a few bags of all the needed ingredients for each member of your party to cook their own food. The server then hands you and your group the bags of ingredients, then promptly points you in the general direction of the kitchen.
How would you feel if you were a client at "yummi food?" What has happened here is that the roles of the server and the clients have been reversed, much in the same way we handle client-server architecture on the modern web. Instead of carefully preparing the content of a webpage on the server-side before sending it to the client (as is the defined behavior mentioned from the Encyclopedia Britannica page on client-server architecture), many servers (websites) offload the job of carefully preparing the content of the webpage onto the client (the web browser), by giving them the ingredients (perhaps what could be called an HTML foundation) and a set of instructions for how to use those ingredients to prepare the webpage to display to the user. While this is not entirely against the client-server concept (the client still receives the necessary information to display something to the user), I believe, personally, that an html document should be ready to be parsed and rendered by the web browser before it is ever sent to the web browser. Yes, I can already hear the screams of "blasphemy" echoing throughout my email inbox, but please hear me out.
Why should the server, which has the job of preparing the content to be sent to the client, offload the job of preparing the content onto the client, effectively making the client responsible for using it's resources and time to do extra things that it shouldn't have to do in the first place. Don't get me wrong, I do believe that there are some things that can't be done by the server, that should or must be done on the client-side, but building and structuring content on an HTML document should not be one of those things. This is an especially important thing to consider when building a website, weather personal or professional, that will be viewed by people with what are basically potatoes by modern-day standards. If you only have two Gigabytes of RAM with an old 32-bit intel CPU in your potato computer, then you aren't going to be running tons of programs written in JavaScript just to generate content on a webpage. It will just cause a lot of headache when your computer starts to slow down and become unresponsive. However, this isn't only the case with old 32-bit monstrosities.
As we move closer to using ARM CPUs with limited RAM capacity as desktop class machines, software will need to be optimized to run on such devices. Such machines are built with efficiency in mind as opposed to raw power. This even applies to modern, 64-bit ARM CPUs. Many websites that I load on my RockPro64 (which I admit is not the most powerful, but it still has 6 processor cores) cause it to slow down, sometimes, even causing it to freeze, forcing me to perform a hard reboot. My point with this being; yes, we have significantly more powerful computers than what we had back around the year 2000, but many of the older computers from 2008 - 2014 are still in operation, and the industry seems to be moving in the direction of efficiency over just cramming more transistors into a CPU. This is why I feel it is important that the web-development industry wakes up to this, and starts using those big, beefy, enterprise-grade servers that they are probably working with on a daily basis, to build the content of a webpage before sending it to the web browser. Please, however, don't misunderstand my intention with this article.
I am not completely against client-side scripting using such things as JavaScript and WebAssembly. In fact, I think there are some valid use-cases for scripting capabilities being included in web browsers. I have no problem with, for example, using a client-side JavaScript program to change the provided CSS stylesheet according to user preference... a task which might be difficult to do with a server-side script. I just don't believe that these client-side scripting technologies should ever be used to offload the job of the server onto the client.
Going back to the restaurant analogy, the roles of the server and the clients have been massively reversed. Things as they are on the web, are entirely backwards from how they should be. The server is giving the client the ingredients and instructions, but not doing the actual work of preparing the food. What a sad world we live in.
Sources:
The Editors of Encyclopaedia Britannica. "Client-server architecture." Encyclopædia Britannica November 23, 2015, https://www.britannica.com/technology/client-server-architecture. Accessed 2 December 2020.
If you have any comments on, or questions about, this article and it's contents, then please send me an email to iansutter@librem.one. If you wish to encrypt your email communications with me, you may use my pgp key, which is located on the contact page of this website. (if you encrypt your emails, please send me your pgp key so I may communicate with you)