I've been thinking a lot about how websites work, specifically the relationship between clients and servers. Today, two different school of thoughts in web development got me pondering about this even more.

Server Purists

On one hand, we have the Server Purists. These folks believe that little or no work should be done on the client, and everything should be evaluated on the server. They argue that the client should only display to the user the final state of that evaluation.

In fact, this school of thought will go as far as making a button click interaction on the client to increment a counter and then send that increment to the server in order to compute it and retrieve the result.

What I've found is that server purists hail from the days when JavaScript ran only on the client, so these folks mostly use languages other than JavaScript on the server. The need to not do any work on the client has led to some interesting technologies like Phoenix Liveview, Rails Hotwire, and of course, Laravel Livewire.

I get it, really. For a while, I considered myself a server purist as well, and that's the whole reason why The Boring JavaScript Stack was so enticing to me - let's move some of the work of building an SPA to the server.

Client Enthusiasts
On the other hand, we have the Client Enthusiasts. These folks are mostly JavaScript lovers who want their websites and web applications to run exclusively on their users' devices. Client Enthusiasts arose from the heyday of SPAs (Single Page Applications).

You would think that since JavaScript runs on both the client and the server, the Client Enthusiasts would take that as a cue to distribute work between the client and the server.

I can make arguments for both sides, and there are valid points, really. But to me, few things are absolutely and completely right in software development. That's why you'd get the classic "it depends" answer in our circle because it really "depends".

Client-Server Pragmatists
What if you don't have to choose between being exclusively a Client Enthusiast or a Server Purist? What if there's a third way? What if you can be a Client-Server Pragmatist?

You see, the web was designed in a client-server architecture. Being a Client-Server Pragmatist is not a new concept; it simply means you are mature enough to distribute work in alignment with the original architecture of the web.

I love this definition on Wikipedia:

The client–server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients.

Based on the definition above, it is evident that work was intended to be distributed between two roles: a server, who provides the resources, and a client, who requests those resources.

I have found that both the Server Purists and Client Enthusiasts, in their insistence on one side being the absolute truth, have negatively impacted web development and user experiences. The Client Enthusiasts, in particular, led us into the era of Spinnerfests by burdening the client with excessive responsibilities.

Client enthusiasts are also the folks who make Ship less JavaScript™️ a thing because they just throw megabytes of JavaScript at their users' devices to download, parse, and evaluate.

Server purists also hurt user experiences because for every interaction, there is a round trip to the server, so their apps are not as snappy as they should be. I don't know about you, but I don't want every button click on a page to make a request to the server to update the UI state.

Client-Server Pragmatists believe that both the client and the server are equally important, and a great user experience on the web must have a balanced distribution of work between the client and the server.

This belief is practical, pragmatic, and grounded in reality.

Read full article