When To Render On The Server And When To Render on the client

For a very long time now all of the web applications that I have built from scratch have been architected as APIs and all human interaction with the applications was via clients to the API. So for example there is usually a client for the web, via web browsers, and various clients for the different models of handhelds. When developing the web clients, I always favor doing most of my rendering on the client. Recently, however, I found myself making a decision to use the server-side rendering approach. This got me reflecting of the two approaches.

Client-side rendering is the approach where when a user makes the initial request to the web application, they are sent most of the HTML, CSS and JavaScript that they may need and what the user sees on a page at a given time is controlled via JavaScript. This is the approach promoted by web frameworks such as EmberJS, EmberJS, BackboneJS, e.t.c. I find that client-side rendering has the following advantages:

  • Mitigation again long network latency. Most of my code is served by hardware located in very distant locations, considering the typical user. This means that data has to travel a longer distance to get to the user than if the hardware that serves the requests were located in closer proximity. Because of this I have to make sure that my network calls are minimal in order to ensure a bearable user experience.
  • Mitigation against low network bandwidths. A lot of the locations where a lot of my target users are located have underdeveloped Internet infrastructure. Internet links tend to have low bandwidth. This means that I have to transfer only the data that I need and nothing more. Using client-side rendering with small JSON payloads enables me to achieve this.
  • Native application-like response times. Because most of the rendering is controlled by JavaScript code, which is already downloaded, the applications’ response times are better for the users than would be the case if every response from the application was being rendered on the server.
  • Cleaner separation of presentation logic from data. Client-side rendering enables me to have less jumbled-up code than when I take the opposite approach. This is because server-side rendering always creates a temptation to add data access logic in the presentation logic.

I find that client-side rendering has the following disadvantages:

  • More time-consuming for a developer. Writing code that leverages client-side rendering takes a lot more time that writing code that does its response rendering on the server.
  • Steep learning curve. For a full-stack developer, the client-side rendering approach presents a steep learning curve. This is because traditionally web applications have been developed using the server-side rendering approach.

Server-side rendering is where for almost every request to a service, the user is sent just the HTML, CSS, JavaScript and images that they need to look at. In other words the server parses the request, does the necessary data access, builds the response as HTML and sends it back to the client. This is the approach where one builds an application powered by Django, Rails, Flask, etc. In this approach, nearly every bit of interaction with the application requires a network call. I have found my self having to take this approach because I am required to write a functional application in a very short period of time, as a way to showcase my skill-set as a full-stack web application engineer. You see for all this approach’s limitations, it favors rapid application development. I find that server-side rendered projects have the following advantages:

  • Faster development times. Since this is the older approach, there are a lot of mature tools that support it. They is also less context switching during development so it promotes rapid application development.
  • Non-steep learning curve. This is also because it is the older approach so most developers will have acquired their skills using this approach.
Like what you read? Give Salym Senyonga a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.