Introduction to Single Page Applications

In the past decade, the web development landscape transformed dramatically with the arrival of Javascript front-end frameworks such as Angular, React, and VueJS that completely changed the way we’ve used to develop our web applications. Such front-end frameworks introduced a new approach to building web applications called Single Page Applications. Sooner, the development community started to acknowledge the benefits and began flocking around this shiny new concept. Today, it has come a long way and has earned its place among developers as the go-to technology for powering up modern web applications that meet and satisfy user expectations.

What is a Single Page Application?

According to Wikipedia, a single page application (SPA in short) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the webserver. This is better explained when you compare the mechanics of a SPA to how a traditional web application works. In a traditional web application, the server is fully responsible for assembling the HTML response that will be rendered in the browser. On the other hand, in a SPA, the client (the browser) is tasked with assembling and rendering the appropriate HTML responses based on user actions. This is also called Client-Side Rendering. When the user sends a request to a SPA, the browser retrieves the necessary HTML and other related assets in its initial request to the server. Once the initial page loading is completed, the Javascript takes over the task of assembling and rendering relevant responses to the user’s request without needing him to make repeated requests to the server. This is not to say that there is no server involvement at all. The server still plays its role behind the scenes. But the page reloads are eliminated. This means, unlike traditional web apps, you don’t have to click on a link and wait for the page to become available. Appropriate resources are dynamically loaded and added to the page in response to the user actions. Sounds cool right? Of course, it does. But not without some drawbacks such as difficulty in SEO, scalability issues, etc. But there are workarounds to address such issues.

Deployment Options

SPA can be deployed as-is, meaning just like the way we’ve described above. Alternatively, SPA can also be deployed as a Static SPA or as a SPA that utilizes Server-Side Rendering aka SSR. Those alternative deployment mechanisms are used to address specific purposes such as to achieve fast loading times, eliminate some of the drawbacks such as SEO issues, etc.

Server-Side Rendering

Earlier you were introduced to Client-Side Rendering, where the browser is responsible for rendering the HTML based on the HTML, CSS and JavaScript received from the server. The biggest drawback of Client-Side rendering is that the slight delay it takes for the page to become fully available from the time it is initially requested. That’s because the Javascript has to do all the heavy lifting with what it receives from the server. At times this can be frustrating to the users as well as has some drawbacks in SEO efforts. This is where Server-Side Rendering comes as a solution. Server-side Rendering or SSR for short is a technique used by Single-Page Applications where the initial response for a request is already generated on the server before sending to the client. This way, the browser receives a response that is ready to be served (Static HTML) without needing it to go through the usual client-side rendering phase which it has to perform with non-SSR-based apps. The result is that the immediate availability of the page, effectively eliminating the delay that was caused by client-side rendering. Even though the browser received some static HTML from the server (similar to that of a traditional web app), the app continues to function as a SPA with a technique called ‘Hydration’ in which the client javascript takes over subsequent rendering of requests by turning the static HTML it received into a dynamic DOM that can react to client-side data changes. Aside from the benefit of SSR that we’ve discussed, as with every other technology, SSR too presents some downsides that you should be aware of and should be prepared to take necessary precautions:

  1. A server-rendered app requires an environment where a Node.js server can run. Rendering a full app in Node.js is going to be a lot more CPU-intensive task and can become problematic if you are not prepared to handle the corresponding server load in case you expect to have a high number of concurrent users.
  2. There can be some limitations on what you could perform with your Javascript framework on the server-side in comparison to what you could perform while on Client-side rendering. For example, the below reference on VueJS explains potential issues that may occur when writing SSR apps:

    https://ssr.vuejs.org/guide/universal.html

Lastly, we’ve got Static SPAs.

What is a Static Web Page?

A static web page is a pre-generated HTML page (with linked assets such as CSS, JavaScript, Images, etc) that is hosted on a server that gets displayed the same for each request it receives. With a static web page, there’s no server-side rendering nor client-side rendering action is performed. It’s just a hard-coded HTML page just lying on the server ready to be served.

When it comes to SPAs, you can pre-render your SPA at build time to generate static HTML pages which can then be served using any static web hosting service without requiring to have some form of dynamic content generation capabilities. Static HTML pages usually offer the optimal loading speed in comparison to any dynamically generated web page due to its simple nature of not having to go through any pre-processing before being served.

To finish things off, the take-out from this article is that the difference between a classic SPA, an SSR based SPA, and a Static SPA lies in a single criterion of where and when does the actual rendering of a page happens.

  • On a Classic SPA – Full rendering of the app happens on the client
  • On an SSR based SPA – Initial rendering happens on the server. After the initial page loading is completed, the client takes over the rendering process by performing the technique called Hydration
  • On a Static SPA – The rendering happens at build time resulting in static HTML files ready to be served over a static web host.

Resources & Further Reading

Below are some of the fantastic references I’ve found and assembled for you to gain more insights into SPAs.

Below are few more references that focus on SSR with Nuxt

Happy coding guys. Thanks for reading!!!

Was this helpful?
+1
0
+1
0
+1
0
+1
0
+1
0
+1
0
+1
0