DEV Community: Valesh

Building DreamHomes: Choosing the Right Rendering Strategy for a Modern Real Estate Platform

Valesh — Thu, 29 May 2025 12:44:59 +0000

In today's fast-paced web, user experience is king. We want websites that load instantly, feel snappy, and are easy to find through search engines. But achieving this across a complex application with diverse needs isn't a "one-size-fits-all" problem. This is where rendering strategies come into play.

Let's dive into a real-world scenario: building "DreamHomes," a modern real estate listing platform. We'll explore how we can strategically choose rendering approaches for different parts of the application to maximize performance, SEO, and user satisfaction.

The Challenge: A Real Estate Platform's Diverse Needs

"DreamHomes" needs to cater to various users and use cases:

First-time visitors searching for properties.
Users Browse detailed listings.
Users actively searching and filtering.
Logged-in agents managing their listings.
Logged-in buyers tracking their favorites.

Each of these scenarios has unique requirements for initial load time, SEO, data freshness, and interactivity. Here's how we'd tackle them:

1. The Homepage: Your Grand Welcome Mat

The homepage is crucial. It's the first impression, needs to be highly discoverable, and feature trending properties that update frequently.

Requirements:
- Highly discoverable by search engines (SEO critical).
- Extremely fast initial load.
- Content (trending properties, featured agents) updates hourly.
Our Strategy: Incremental Static Regeneration (ISR)
- Why? Pure Static Site Generation (SSG) would be lightning-fast but wouldn't handle hourly updates gracefully without constant redeploys. Pure Server-Side Rendering (SSR) would handle freshness but might be slower on the initial byte than a pre-built page.
- ISR allows us to generate the homepage HTML at build time (like SSG) for blazing-fast initial delivery from a CDN. But we can configure it to "revalidate" or regenerate the page in the background after a specified interval (e.g., every 60 minutes). This gives us the best of both worlds: static speed for first-time visitors and near real-time freshness for regularly updated content, all while satisfying search engine crawlers with pre-built HTML.

2. Property Listing Detail Page: The Core Business

Each property's detail page is fundamental. It contains rich information and is a prime target for search engines.

Requirements:
- Crucial for SEO.
- Property data (price, status, description) can change at any time.
- Includes an "Enquire Now" form (highly interactive, not SEO critical).
- Includes "Similar Properties" section (dynamic recommendations).
Our Strategy: Server-Side Rendering (SSR) for the Main Content + Client-Side Rendering (CSR) for Dynamic/Interactive Elements
- Why for Main Content (SSR)? Since property data can change at any moment (an agent updates a price, or a property goes off-market), we cannot rely on build-time generation. SSR ensures that every time a user or a search engine crawler requests a property page, they get the absolute latest data rendered directly into the HTML. This is paramount for accuracy and SEO.
- Why for "Enquire Now" Form & "Similar Properties" (CSR)?
  - The "Enquire Now" form is an interactive client-side experience. It doesn't need to be indexed by search engines, and rendering it on the client reduces the server's workload.
  - "Similar Properties" are dynamic recommendations that might involve personalized logic or separate API calls. Fetching and rendering these on the client-side after the main page has loaded keeps the initial SSR payload lean and allows for flexible updates. This is a common pattern for "below the fold" content or components that aren't critical for the initial content display or SEO.

3. Search Results Page: The Interactive Powerhouse

This page is all about dynamic filtering and instantly updated results.

Requirements:
- Results are highly dynamic, changing with every search query and filter.
- Includes filters that instantly narrow down results without a full page refresh.
- Not necessarily critical for SEO beyond the initial search page URL itself.
Our Strategy: Client-Side Rendering (CSR)
- Why? Given the highly dynamic and interactive nature of search and filtering, CSR is the natural choice. Every filter change would trigger a new data fetch and an update of the displayed results directly in the browser. This provides a fluid, app-like experience without constant full page reloads. Since the specific search results are unique to each query and don't require individual indexing, the SEO benefits of SSR/SSG are less relevant here.

4. User Dashboard: Personalized Hubs

The dashboard is for logged-in users (agents and buyers) to manage their personalized content.

Requirements:
- Requires user authentication.
- Content is entirely personalized and dynamic.
- SEO is irrelevant.
Our Strategy: Client-Side Rendering (CSR) with Strategic Lazy Loading
- Why (Primary CSR)? Since the content is personalized and behind a login, SEO is not a concern. CSR allows for a highly interactive and responsive user experience.
- Why (Strategic Lazy Loading)? Dashboards can become "heavy" with many features (e.g., complex charts, large tables, numerous settings panels). Implementing code splitting and lazy loading (using React.lazy and Suspense) is crucial here. Instead of downloading all the JavaScript for every dashboard feature upfront, we only download the code for a specific feature (like a "Listings Management" table or a "Detailed Analytics Chart") when the user actually navigates to that section. This significantly reduces the initial load time of the dashboard and improves perceived performance.
- (As an advanced consideration, if the dashboard were exceptionally heavy and even initial JS load was an issue, one could consider partial SSR combined with client-side hydration for very critical "above the fold" sections, but this adds complexity and is usually overkill for authenticated dashboards where lazy loading suffices.)

The Power of Hybrid Rendering

As you can see, there isn't one "best" rendering strategy for an entire application. Modern web development thrives on hybrid rendering, where you strategically combine these approaches based on the specific needs of each page or even each component.

By carefully considering SEO, data freshness, interactivity, and performance goals, we can build robust, fast, and user-friendly applications like "DreamHomes" that truly stand out.

How to host your static web applications on github pages

Valesh — Mon, 23 May 2022 15:40:55 +0000

Github provides a free hosting service to help your websites go live online. It is called Github Pages. Github Pages builds a static website from the HTML, CSS and Javascript files in your repository. Let's see how.

(For the purpose of this tutorial, we'll assume you already know how to create a repo and add files to it.)

Step 1:
Go to your repo, click on 'Settings'

Step 2:
Click on 'Pages' in the left sidebar

Step 3:
Under the 'Source', click on 'None'.

Step 4:
From the dropdown menu, choose your main branch and click Save.

Step 5:
That's it! Now your site is ready to be published. Wait a couple of minutes for your site to be live on the given link!

If you want to host a web application or your personal portfolio on yourusername.github.io, create a repo with the name 'yourusername.github.io' and follow the above steps.

Pro Tip:
If you want to host your custom domain on github, first enter your domain name in the 'Custom Domain' field and hit 'Save'. Then point the A record of your domain to the following ip addresses:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

Let me know in the comments if you found it helpful!

em vs rem - Most confusing CSS units explained

Valesh — Sun, 01 May 2022 10:31:20 +0000

em and rem are two of the most commonly used CSS relative units. They are also one of the most common sources of confusion among beginners. In this article, we'll see what exactly they are and how to use them.

Relative Units

Relative units derive their sizes from other properties. Unlike absolute units(like pixels, inches etc.) whose sizes are independent of other units, the sizes of relative units change according to that of other properties.

In particular, em and rem are relative to the font sizes of parent and root elements respectively. Let's understand with this an example.

em vs rem

First, we'll define two containers, one each for em and rem respectively.

<div class="em-parent">
  <p>em-size</p>
</div>

<div class="rem-parent">
  <p>rem-size</p>
</div>

Now, let us set the font-sizes for the root element and the children of em-parent and rem-parent containers.

:root {
  font-size: 32px;
}

.em-parent p {
  font-size: 1em;
}

.rem-parent p {
  font-size: 1rem;
}

As we can see from the result below, both the child elements derive their sizes from root element (1em = 1rem = 32px).

Now let's see what happens to the font-sizes of the child elements when we set the font-sizes of their parent containers.

:root {
  font-size: 32px;
}

.em-parent {
  font-size: 64px;
}

.em-parent p {
  font-size: 1em;
}

.rem-parent {
  font-size: 64px;
}

.rem-parent p {
  font-size: 1rem;
}

As we can see from the result, the em unit is deriving its size from its parent container, whereas the rem unit remains fixed to the font-size of the root element, unaffected by the font-size of its parent container. So in this case, 1em becomes 64px and 1rem remains 32px;

So remember, em derives its size from its parent, and in the absence of the parent's font-size, it derives its size from the root element. Whereas rem always remains fixed to the font-size of the root element.

Now that we understand the basic difference between em and rem, let's get into their application.

How to use em and rem
em and rem are most commonly used to set font-size, padding and margin of the elements. But another difference between em and rem is that, em has a compounding effect on padding and margin, whereas rem always remains constant. That may sound confusing. So, let's understand it with an example.

We'll use two buttons to demonstrate this example.

<div class="button-1">
  <button>button 1</button>
</div>

<div class="button-2">
  <button>button 2</button>
</div>

Now let's set the properties of both the buttons in em.

:root {
  font-size: 16px;
}

.button-1 {
  font-size: 16px;
}

.button-1 button {
  font-size: 1em;
  padding: 1em;
  margin: 1em;
}

.button-2 {
  font-size: 16px;
}

.button-2 button {
  font-size: 1em;
  padding: 1em;
  margin: 1em;
}

Let's increase the font-size of button 1 to 2em(2 * 16 = 32px) and see what happens.

.button-1 button {
  font-size: 2em;
  padding: 1em;
  margin: 1em;
}

Apart from increase in its font-size, something interesting has just happened in button 1. Can you notice it? No? It might be a bit difficult to notice with naked eye. So, let me show what happened.

Notice that the padding and margin of button 1 have also increased to 32px(2em) even though they are set to 1em. This is because of the compounding effect of em. While the em of child derives its size from its parent, the em of padding and margin of the child are derived from its own font-size.

So in this example,
1em of child element = font-size of parent container = 16px;
1em of padding/margin = font-size of the element = 2em = 32px;

Now, let's also increase the font-size of button 2 to 2em and set the padding and margin to 1rem each. This will help us visually understand the difference between em and rem better.

The padding and margin in button 2 have remained 16px each. Ideally, we would always want the padding of an element to remain proportionate to its font-size. Notice in the above example, the button 2 looks congested when we increase its font size, but keep its padding fixed to 1rem.

So, it is a good practice to always set the padding of elements in em like we did in button 1.

And as we increase or decrease the font-sizes of the elements, we would want the spacing between them to remain constant. That is why it is a good practice to set the margin in rem. Let's make the change in our code and see the difference.

.button-1 button {
  font-size: 2em;
  padding: 1em;
  margin: 1rem;
}

.button-2 button {
  font-size: 2em;
  padding: 1em;
  margin: 1rem;
}

Notice that if we set the margin in em, the elements drift apart when we increase their font-sizes, owing to the compounding effect of em. But if we set the margin in rem, the spacing between the elements remains constant.

Conclusion:
Many developers often use em and rem interchangeably to set padding and margin. But this can lead to unintended consequences, namely resulting in uneven spacing issues within the elements and in the layout of the website. That is why it's important to understand in what ways em and rem differ.

Let me know in the comments if this article has helped you understand the difference between em and rem better.

CSS Box-Model Simplified

Valesh — Thu, 21 Apr 2022 07:45:24 +0000

Each element on a web page is wrapped around by a box. The arrangement of these boxes makes up the layout of the website. Building layouts is a crucial part of front-end development which is what makes understanding the box-model indispensable.

Features of the box:
Each box has padding, margin and border.

Padding: The space between the content and the border.

Margin: The space around the border.

Border: Indicates the dimensions of the box.

https://commons.wikimedia.org/wiki/File:Box-model.svg

Dimensions of the box:
The dimensions of the box are computed as follows:

width of box = width of element + padding-left + padding-right + border-left+ border-right

height of box = height of element + padding-top + padding-bottom + border-top + border-bottom

Take a look at the following CSS for example:

div {
  width: 100px;
  height: 100px;
  padding: 10px;
  border: 5px solid red;
  margin: 10px;
}

width of the box = width of element (100px) + padding-left(10px) + padding-right(10px) + border-left(5px)+ border-right(5px) = 130px

height of the box = height of element(100px) + padding-top(10px) + padding-bottom(10px) + border-top(5px) + border-bottom(5px) = 130px

Therefore, the dimensions of the box are 130px x 130px.

Notice that while we intended the element to be 100px x 100px, the padding and border added 30px to both width and height. This can make our elements overflow and compete with each other for space, messing up the layout.

Box Sizing:
The solution for this is a CSS property called box-sizing. The default value of box-sizing is set to content-box.

Content-box: Includes width and height of only the element. The padding and the border are not included.

Therefore, padding and border add extra pixels to the element, thus increasing the overall dimensions of the box.

The alternate option is border-box.

Border-box: Includes padding and border. As padding and border are altered, the dimensions of the element are adjusted accordingly, to keep the dimensions of the box fixed.

Let's apply border-box to our previous example.

div {
  width: 100px;
  height: 100px;
  padding: 10px;
  border: 5px solid red;
  margin: 10px;
  box-sizing: border-box;
}

Notice that the dimensions of the box remain 100px x 100px even after adding padding and border. This is achieved by automatically adjusting the dimensions of the element to 70px x 70px, in order to accommodate padding and border.

Tip:
Set the box-sizing to border-box using the universal selector(*), to reset the default box-sizing property of all elements, at the beginning of your stylesheet.

* {
margin: 0;
padding: 0;
box-sizing: border-box;
}

If this article helped your understanding of the box-model, let me know in the comments!

Random Quote Generator

Valesh — Wed, 01 Dec 2021 15:08:38 +0000

New Year Countdown Timer

Valesh — Thu, 25 Nov 2021 05:03:48 +0000

Text To Speech Converter

Valesh — Mon, 22 Nov 2021 16:23:15 +0000

Hover Board

Valesh — Sun, 21 Nov 2021 05:18:48 +0000

Incrementing Counter

Valesh — Mon, 15 Nov 2021 13:50:11 +0000

Progress Steps

Valesh — Sun, 14 Nov 2021 05:43:24 +0000

Expanding Cards

Valesh — Sun, 14 Nov 2021 04:39:12 +0000

Social Media Icons Hover Animation

Valesh — Mon, 11 Oct 2021 09:43:20 +0000