The Evolution of Web Apps: Client-Side Rendering and Its Challenges

The Web app Spring

Since the introduction of Angular.js, and perhaps even earlier, there's been a consistent and widespread push to make the web fully client-driven, more "mobile app-like" and dynamic. Users now expect the same experience they receive in their mobile apps when visiting web applications. Their expectations are justified, as content and features have grown increasingly complex. Websites have evolved beyond their initial static nature into dynamic, feature-rich web applications. Since 2012, a multitude of frameworks and libraries like Angular, React, Vue, and even newer ones like Svelte have emerged. One common characteristic among them is client-side rendering, but this is just a first step.

How Web app frameworks/libraries work

In a typical web app framework/library, you are provided with utilities and structure that allow you to render dynamic components in the browser DOM. This capability existed even in the jQuery days, but it was rather cumbersome and very resource-intensive. One key feature that enabled these new technologies to transform the web into an application-like experience was the introduction of the Virtual DOM by React and similar ideas by Angular and Vue. In essence, whenever a new element is rendered or an existing one modified, these changes occur in a memory-stored representation of the browser DOM, managed by the respective library or framework. Every few milliseconds, this DOM is "flushed" into the real DOM, and the user can see what you intended. This process is much more performant since updates are performed in bulk, allowing for optimization and a radical speed up. Meanwhile, these technologies provide different paradigms on how you can structure your app and render it, which can be drastically different from one another. Despite the differences, all these technologies render your code client-side, and the user's browser has to do all the work, unlike server-rendered technologies like PHP where the server does the computation and the browser shows the final result.

Out with the old, in with the old?

If you've been following the news, in the recent months React 18 introduced a new feature to the masses: "Server Components". Server components allow us to run code and render components on the server, without having the browser calculate what it needs to show or shipping expensive code (performance-wise) to the browsers. For many, this appears to be a step backward, reverting to older technology. But is it really?

The 'Why' Behind the Shift to Dynamic Apps

The shift from static websites to dynamic apps is clear, but why is server-side rendering important or why was it ever? Simply put, all that dynamism is provided by a lot of logic and/or server requests for data. Especially data. A typical web application might make 10 or more backend calls to fetch data for its initial load, depending on the level of optimization. Each request consumes resources and adds to the processing time, and the browser also maintains a general request limit per open tab. This effectively means that things go into a queue and wait to be executed, rather than happening all at once.

The Challenges of Client-side Rendering

In contrast, a server environment typically doesn't have such constraints. It has access to ample CPU and RAM, has rapid internet connectivity, and is likely located next to your DB anyway. Thus, a web app that takes 6-10 seconds to fully load on your browser can be rendered on the server in less than a second. In the battle for user attention, these seconds make a significant difference. However, the transition from client-side rendering to server-side is not without challenges, and many web developers have found themselves in a land of confusion when dealing with this paradigm shift. But that's a topic for another article. Stay tuned!

Stay tuned for the next article where we dive into the world of server-side rendering, the first attempts, the challenges, and the new solutions offered by technologies like React's Server Components.