Elanat Framework

Posted on Feb 23

Loading a View Inside Another View in CodeBehind (SSR vs CSR)

#tutorial #dotnet #beginners #backend

In this tutorial, you will learn two different approaches to compose modular web pages using the CodeBehind framework: Server-Side Rendering (SSR) with LoadPage, and Client-Side Rendering (CSR) with WebForms Core."

Server-Side Rendering (SSR) means the server fully generates the HTML before sending it to the browser.

Client-Side Rendering (CSR) means part of the page is loaded or generated after the main page has already been delivered to the browser.

In modern web development, it is often necessary to divide a web page into independent and modular parts so that each part can be managed according to the type of data, level of dynamism and need for customization.

There are multiple ways to load one page inside another. However, not all approaches are optimal in terms of performance and scalability. In this article, we focus only on two recommended strategies. Here we will teach you two approaches, one of which is based on SSR and the other is CSR.

Let's start with the server-side approach.

Load Page Example

In this example, we create a simple user profile module that will later be injected into another page.

Creating the Module

Module ("/module/user_profile.aspx")

@page
<div style="position: fixed; top: 10px; right: 10px; display: flex; align-items: center; gap: 10px;">
    <span>🔔</span>
    <img src="https://ui-avatars.com/api/?name=adriano" style="width: 40px; height: 40px; border-radius: 50%;">
    <span>Adriano Armisen</span>
    <span>▼</span>
</div>

Server-Side Rendering (SSR) with LoadPage

In this case, in the View page, using the LoadPage method, we can add the desired page to the desired section of the HTML page.

Using LoadPage in the View

@page
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>CodeBehind Framework Call Page SSR Mode</title>
</head>
<body>

  @LoadPage("/module/user_profile.aspx")

  <h1>CodeBehind Framework</h1>
  <p>CodeBehind Framework is a lightweight ASP.NET-based web framework that simplifies development by separating HTML structure from server-side logic without relying on MVC or Razor.</p>

</body>
</html>

How LoadPage Works?

When using LoadPage, the server executes the requested page and injects its rendered HTML into the current page before sending the final output to the client.

When You Should Avoid SSR

However, SSR is not always the best solution. In some scenarios, a different approach is more efficient.

Consider a page where some users are logged in and some are using its features without registering. On many websites, a logged-in user sees a menu at the top of the page that is specific to their account, while the rest of the site is the same for all users.

One bad decision in this scenario is to render this user-specific menu as SSR and send it to the user along with the entire HTML of the page. In this case, the server is forced to generate a different version of the HTML for each user. The result of this is:

Prevents full-page CDN caching
Reduced effectiveness of server-side and client-side caching
Increased processing pressure on the server
Loss of scalability at high traffic

Therefore, using SSR for user-specific content can negatively impact performance and caching strategy in high-traffic applications.

While the main body of the page can be fully cacheable and shared by all users, only the login-specific part needs to be loaded separately.

This is where AJAX comes into play;
Instead of generating a completely customized HTML, you can send the main page as a public, cacheable page, and then retrieve and replace the user-dependent parts separately and dynamically.

Of course, using AJAX increases the complexity of the architecture and state management on the client side to some extent. You have to define separate endpoints, manage login status, handle errors, and in some cases encounter problems such as UI synchronization or loading state.

But fortunately, in the CodeBehind framework, you can use WebForms Core technology to add different parts of the page in a modular and independent way after loading the main page, without the need to directly implement AJAX.

Client-Side Rendering (CSR) with WebForms Core

WebForms Core is a client-side execution layer in the CodeBehind framework that allows dynamic content injection after the initial page load.

In this approach:

First, the main body of the page is sent as a public, cacheable page.
Then, the controls or components dependent on the user's state are processed separately and added to the output after the initial execution of the page.
This process is done without the need to write manual AJAX code.
At the same time, the page structure remains discrete and scalable.

Example

@page
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>CodeBehind Framework Call Page CSR Mode</title>
  <script type="module" src="/script/web-forms.js"></script>
</head>
<body>
@{
  WebForms form = new WebForms();
  form.AddTextToUp("<body>", Fetch.LoadUrl("/module/user_profile.aspx"));
}

@form.ExportToHtmlComment()

  <h1>CodeBehind Framework</h1>
  <p>CodeBehind Framework is a lightweight ASP.NET-based web framework that simplifies development by separating HTML structure from server-side logic without relying on MVC or Razor.</p>

</body>
</html>

Fetch.LoadUrl is not executed on the server. Instead, it generates instructions that tell the client to asynchronously retrieve the module page after the main page loads
AddTextToUp injects the loaded content to the top of the <body> element.
ExportToHtmlComment renders the required instructions for WebForms Core to process the dynamic content on the client side.

It is recommended to implement client caching in CSR mode for the module page so that it is requested from the server only once.

The output of both methods is the same for the end user, but CSR mode makes one more request to the server.

CSR helps maintain full-page CDN caching while isolating user-specific components into independent requests.

Final Result

The following screenshot shows the final rendered HTML in the browser for both approaches.

Comparison of CSR and SSR

The following table summarizes the differences between SSR and CSR in CodeBehind:

Feature	SSR	CSR
Rendering Location	Server	Client
Extra HTTP Request	No	Yes
CDN Friendly	Limited for user-based content	High
Complexity	Low	Medium
Best Use Case	Shared content	User-specific modules

Note: This is only a demonstration of page composition. In real applications, always validate authentication and authorization on the server side, even when using CSR.

@page
@if (IsUser)
{
<div style="position: fixed; top: 10px; right: 10px; display: flex; align-items: center; gap: 10px;">
    <span>🔔</span>
    <img src="https://ui-avatars.com/api/?name=adriano" style="width: 40px; height: 40px; border-radius: 50%;">
    <span>Adriano Armisen</span>
    <span>▼</span>
</div>
}

Conclusion

In this article, we explored two approaches for composing modular pages in the CodeBehind framework. SSR using LoadPage is simple and efficient for static or shared content, while CSR using WebForms Core is more suitable for user-specific and dynamic components that should not affect page caching. Choosing the right strategy depends on performance requirements, scalability, and architecture design.

DEV Community