DEV Community

Cover image for The Return of Server-Side Rendering
Huỳnh Nhân Quốc
Huỳnh Nhân Quốc

Posted on

The Return of Server-Side Rendering

#serversiderendering #jamstack #frameworkjs #clientsiderendering

☕ A Little Context

Lately, I’ve seen a lot of conversations about YouTube ads, tracking systems, and the mysterious role of server-side rendering on YouTube’s backend.

This isn’t another technical doc or SEO article.

This is my story — and what I’ve learned about Server-Side Rendering (SSR) and Client-Side Rendering (CSR) through my own experiments.

⚙️ Client-Side Rendering (CSR)

Client-Side Rendering means that your browser (the client) downloads all necessary JavaScript files and executes them locally to render the page.

Everything — from fetching data via APIs to building the DOM — happens inside your machine.

This became incredibly popular over the past decade, thanks to the rise of frameworks like Angular, React, and Vue.

Later, “meta-frameworks” such as Next.js and Nuxt.js evolved the idea with pre-rendering — blending SSR and CSR to balance performance and dynamic interactivity.

Pre-rendering is a hybrid approach: part static, part dynamic, but still built on the foundation of JavaScript frameworks.

💡 Server-Side Rendering (SSR)

Server-Side Rendering, on the other hand, pushes rendering to the server — your hosting or cloud infrastructure.

The heavier the server, the faster it can pre-generate and send HTML to clients.

But if your traffic spikes and your server can’t keep up, bottlenecks happen.

Classic examples:

  • PHP (WordPress, Laravel)
  • Java (Spring Boot)
  • C# (ASP.NET)
  • Python (Django, Flask)
  • Ruby on Rails These frameworks have powered the web for years. SSR isn’t new — it’s the foundation of everything modern frameworks are trying to reimagine.

⚖️ CSR vs. SSR — My Take

Let’s be real: both have pros and cons.

CSR

  • Pros: Lightens the server load.

  • Cons: Depends heavily on the client’s hardware and network.

    SSR

  • Pros: Great for SEO and security.

  • Cons: Heavy on the server and can become a performance bottleneck if scaled poorly.
    But for me, it’s not about which is better.

    It’s about what you’re trying to achieve.

🔍 SEO: The Invisible War

If you build websites, you already know this:

A site without visitors is just another lonely file on the internet.
SEO (Search Engine Optimization) is what keeps your project alive.

SSR handles SEO beautifully because crawlers can instantly index pre-rendered HTML.

CSR often requires pre-rendering tricks or workarounds for that.

Sure, Pre-rendering frameworks like Next.js are powerful —

but real SEO success depends on strategy and long-term system thinking.

When you deeply understand your rendering stack, you can do clever optimizations only possible on the server level.

So yes — SSR wins in SEO, but only if you know how to optimize it.

🧠 Popularity and Trends

In the last ten years, JavaScript frameworks have taken over the web.

The endless React vs Vue vs Angular debates still go on.

Meanwhile, WordPress quietly dominates the internet — proof that “old tech” can still be incredibly effective.

But remember: framework ≠ language.

If you need a quick blog, landing page, or store — go ahead, use WordPress.

If you’re building a system meant to grow, you’ll want something more structured, like Laravel or a modern JS stack.

And yes — Facebook still runs on PHP.

No matter how much they innovate, their core language remains.

So the future?

Hybrid JavaScript frameworks powered by Server-Side Rendering.

🔐 Security Matters

Let’s be honest:

“When you give away your code, you give away part of your security.”
With Server-Side Rendering, sensitive logic stays hidden on the server.

Only processed data is sent to the client.

That alone gives SSR a clear advantage in security.

But in the end, it all depends on your developer mindset — and how you connect the front-end and back-end.

“The more popular something becomes, the harder it is to secure.”

🏢 Companies Using Each

This isn’t a deep audit — just a few quick observations:

Client-Side Rendering

  • Tiki (Vietnam) — reportedly uses Next.js.

  • Shopee — mostly CSR-based, with some hybrid features.

    Server-Side Rendering

  • Thế Giới Di Động and Điện Máy Xanh — both rely heavily on SSR.

    You can see how well it works for their SEO and performance.

    🌐 The Future: Hybrids and AI

CSR compensates with pre-rendering to overcome SEO limits.

SSR evolves by offloading some logic to the client to reduce server stress.

But as AI systems grow stronger, CSR faces new challenges.

AI can decompile, analyze, and exploit client-side logic faster than ever before.

At some point, the balance of client vs. server may redefine itself — and we’ll all have to adapt.

🧩 My Own Stack

Personally, I use Server-Side Rendering,

but I mix in client-side components (vanilla JS) for fast, interactive tasks.

Every component is modular, built from scratch, and rendered securely on the server —

especially for sensitive keys and operations.

🔭 Where My Ideas Come From

I started with Angular, then explored JAMstack.

After years of trial and error, I built my own mini-architecture — combining Web Components, custom JS, and my own server rendering system.

It’s not a framework.

It’s a mindset:

Control the client, control the server, control the API.

🧠 Building for Technological Independence

Hi, I’m Huỳnh Nhân Quốc —

a dreamer chasing technological independence.

I’m building my own modular ecosystem — one piece at a time.

Modules I Build

  • Blog posts
  • Job boards
  • Authentication
  • URL shorteners
  • QR payment systems Each module can be deployed, rented, and reused. My long-term vision?

A cloud-based SaaS ecosystem — “rentable tech modules.”

☁️ SaaS and Headless API

SaaS (Software as a Service) means offering your product as a service —

like Google Workspace, Adobe Creative Cloud, or Notion.

You pay for what you use, and everything lives online.

Headless APIs take it further.

Developers can build only the front-end and pay based on API usage —

reducing initial costs for startups.

A perfect modern example?

ChatGPT’s API pricing — pay per request token.

This is the future: Headless SaaS ecosystems where every service is modular, rentable, and interconnected.

✍️ Final Thoughts

Thank you for reading about Client-Side Rendering vs Server-Side Rendering —

and my small dream of building my own path between them.

This article also marks a personal milestone —

the birth of my first Blog Module.

I’m still learning, still building, and still dreaming.

If you share this mindset — let’s build something independent together.

NOTES

More about me

Thanks for reading Huỳnh Nhân Quốc's article! Subscribe for free to receive new posts and support my work.

Top comments (0)