All the ways Javascript ends up in your server
2025-08-06
"'In the beginning the Universe was created. This has made a lot of people angry and been widely regarded as a Dick move'- Hitchhiker's Guide to the Galaxy"
PS : this is for people who asked me why js is the way it is
a deep dive into all of js.
The History of Javascript on the Client
Picture this: It's 1995. The web is a graveyard of static pages—lifeless text and images that never change, never respond. You click a link, wait for a new page to load. That's it. No animations, no real-time anything.
Then Brendan Eich, A netscape engineer and language designer, gets handed an impossible task: create a programming language for the web. In ten days. Ten days. What should have been months of careful design became a frantic sprint that would accidentally reshape the entire internet.
Javascript wasn't supposed to conquer the world. It was supposed to add simple interactions—maybe validate a form, change some text. But something strange happened. Developers discovered they could do more with this scrappy little language than anyone imagined.
Fast-forward to the early 2000s, and Javascript had become the invisible engine powering every website you visited. What started as a quick hack had evolved into the foundation of the modern web.
The Creator of StackOverflow 
Jeff Atwood has a great quote about Javascript:
“Anything that can be written in JavaScript, will eventually be written in JavaScript.” - Atwood's law
Have you ever seen a fire spread across a forest? It starts small , everytime ... maybe a couple of feet. But it grows and grows, and eventually it becomes a forest fire. That's what happens when you have a language accessible to everyone, it spreads like a wildfire , burning through complexity and ending up on systems that are not designed to handle it, like the web.
A phenomenon like this was only seen once... by a single other program that predates javascript. you know it and love it....
Atwood's Law became a self-fulfilling prophecy. this was the case in 2000s as well. Just like doom , people found ways to embed javascript in their systems, and it became the norm. Inventions like the browser, the DOM, and the event system were all born out of the need to interact with the web.
Some major innovations in the javascript land was the introduction to the [EVENT LOOP] .
the event loop is an interesting topic of debate , my favourite interview question to ask or be asked is simply
console.log("ONE!");
setTimeout(() => {
console.log("TWO!");
}, 0);
Promise.resolve().then(() => {
console.log("THREE!");
});
queueMicrotask(() => {
console.log("FOUR!");
});
(async () => {
console.log("FIVE!");
})();
console.log("SIX!");
// Result ->
// ONE!
// FIVE!
// SIX!
// THREE!
// FOUR!
// TWO!
*Question and Solution by 
The event loop truly made javascript Asynchronous and non-blocking , handling all the concurrent requests and responses in a single thread.
This is a very important concept to understand, and it's the reason why javascript is so fast and performant. and some people did , which brings us to Node.js.
Node.js and the beginning of Javascript on your backend
Ryan Dahl was a math research student in Upstate New York, tinkering away in 2009 on a project that would change the web forever: [Node.js]. At the time, the idea of running JavaScript
outside the browser—on the server—was almost unthinkable. Ryan didn’t even set out to use JavaScript at first. But as he explored the possibilities, he realized that JavaScript, powered by Google’s lightning-fast
V8 engine, was uniquely suited for building non-blocking, asynchronous servers. The event-driven model, which had already made JavaScript so powerful in the browser, could be harnessed to handle thousands
of concurrent connections on the backend, all within a single thread.
This is a good moment to pause and ask: why did JavaScript become so popular on the backend? Sure, it’s convenient to use the same language on both the client and the server, but there’s more to it. Traditional server languages like Java, PHP, or Ruby typically spin up a new thread for every incoming request, which can quickly exhaust system resources and limit scalability. Node.js, by contrast, uses an event loop and a callback-based model to handle I/O operations asynchronously. This means it can juggle many connections at once, without blocking the main thread or spawning a horde of new ones. Suddenly, building scalable, real-time web applications became much more accessible.
Of course, the early days of Node.js weren’t all smooth sailing. There were major hurdles—especially around cross-platform compatibility (Windows support was a pain), and there was no package manager or build tooling to speak of. But the community rallied. 
With these foundations in place, Node.js exploded in popularity. It was revolutionary: suddenly, JavaScript wasn’t just for the browser—it was everywhere. But as with any revolution, new challenges emerged. If Node.js was to be the backbone of modern backends, it needed more than just raw speed and non-blocking I/O. It needed developer-friendly tools and frameworks.
There were problems in the initial days , in particular there were compatibility issues with asynchronousity in windows , there were no package managers and no build tools, but there was hope for the future. People like
Node.js was born , grew like a weed and became the most popular server runtime for javascript. This was revolutionary back then, but there were problems , that needed to be solved. If Node could serve as a foundation for backend, does it have the right tools to build a modern backend?
sure there were tools like [Express] and [Koa] , but they were the right tools for the job.
the syntax was easy to learn , and now is deeply ingrained in the language.
const express = require('express')
const app = express()
const port = 3000
app.get('/', (req, res) => {
res.send('Hello Express!')
})
app.listen(port, () => {
console.log(`Example app listening on port ${port}`)
})
Express allowed you to write a server that was not only fast but also scalable, but it was not a good fit for a backend, People found it easy to extend express with their frontend as well , they statically hosted their frontend in express ( a practice that stretches till this very day with React SSG on express).
// server.js
const express = require("express");
const path = require("path");
const app = express();
const port = process.env.PORT || 3000;
const REACT_BUILD_DIRECTORY = "dist";
// --- Middleware to serve static files ---
// This tells Express to serve all static files (like your index.html, JS, CSS, images)
// from the specified directory.
app.use(express.static(path.join(__dirname, REACT_BUILD_DIRECTORY)));
app.get("*", (req, res) => {
res.sendFile(path.join(__dirname, REACT_BUILD_DIRECTORY, "index.html"));
});
app.listen(port, () => {
console.log(`Express server running on port ${port}`);
console.log(`Serving static files from: ${path.join(__dirname, REACT_BUILD_DIRECTORY)}`);
console.log("Make sure your React app is built into this directory.");
});
There were a lot other improvements in the ecosystem as well, like [TypeScript] , which is a superset of Javascript that allows you to write typesafe code, which helps you catch errors before they happen , know all the properties of an object before you use them and so on.
const user = {
firstName: "Angela",
lastName: "Davis",
role: "Professor",
};
console.log(user.pincode); // undefined , you will never know
// typescript
const user = {
firstName: "Angela",
lastName: "Davis",
role: "Professor",
}
console.log(user.name)
// Property 'name' does not exist on type
// '{ firstName: string; lastName: string; role: string; }'.
and [Jest] , which is a testing framework that allows you to test your code in a synchronous way. to demonstrate the power of Jest, let's write a test for our sum function.
// sum.js
function sum(a, b) {
return a + b;
}
module.exports = sum;
// sum.test.js
import
const sum = require('./sum');
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
// package.json
{
"scripts": {
"test": "jest"
}
}
Javascript on the server was now capable as ever... it was growing. We had phases like No-SQL , GraphQL , and the rise of the serverless world, where you could build applications that were not bound to a server, but instead were executed on random computers anywhere across the world to provide a better developer experience. concepts of a server and client started to blur, and the new web started to take shape.
// app/page.tsx (App Router in Next 15)
export default async function HomePage() {
// server time actually :)
const time = new Date().toISOString();
return (
<main>
<h1>Hello from Next.js 15 SSR!</h1>
<p>Server time: {time}</p>
<button onClick={() => alert("Hydrated!")}>Click me</button>
</main>
);
}
What the Server Sends (Initial HTML), is very interesting ... when you make a request to https://localhost:3000/ Next.js 15 server renders the React component into HTML and streams it to the browser.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charSet="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>Home</title>
<link rel="preload" as="script" href="/_next/static/chunks/main.js">
<link rel="preload" as="script" href="/_next/static/chunks/app/page.js">
</head>
<body>
<div id="__next">
<main>
<h1>Hello from Next.js 15 SSR!</h1>
<p>Server time: 2025-08-31T15:45:20.123Z</p>
<button>Click me</button>
</main>
</div>
<!-- Next.js hydration scripts -->
<script src="/_next/static/chunks/webpack.js" defer></script>
<script src="/_next/static/chunks/main.js" defer></script>
<script src="/_next/static/chunks/app/page.js" defer></script>
</body>
</html>
The HTML already contains the h1 + time, so the page is readable immediately. The button has no event handlers yet it’s static HTML at this point.
Once the JavaScript bundles load, React hydrates the HTML. That means it, Scans the existing DOM (#__next div).Attaches React event listeners (e.g., onClick for the button).Turns the static page into a live React app.
After hydration, clicking the button works, because React attached the handler defined in the component. The idea was soo productive, that many other framework authors took notice of it and started to implement it in their own frameworks. like [Svelte] , [Solid], [Nuxt].
There was still a new improvement to be made in this space , and the final topic of uis is streaming, streaming changed the way we think about SSR, the idea being , what if we could progessively ship html to the browser , instead of waiting for the page to server render completely. what if , we could await for some data later on ... and then fill up the html with that data ?... that turned some gears in the right direction.
// app/page.tsx (Next.js 15, App Router, React 19)
async function getData() {
// simulate slow fetch
await new Promise(r => setTimeout(r, 2000));
return "This data came from the server!";
}
export default async function Page() {
const data = await getData();
return (
<main>
<h1>Hello from Next.js 15 Streaming SSR!</h1>
<p>{data}</p>
</main>
);
}
Here, getData() delays for 2s → which demonstrates React’s async rendering and streaming.
<!DOCTYPE html>
<html>
<head>
<meta charSet="utf-8"/>
<title>Home</title>
</head>
<body>
<div id="__next">
<main>
<h1>Hello from Next.js 15 Streaming SSR!</h1>
<p>
<!-- React leaves a placeholder here -->
<template id="P:0"></template>
The browser can already show the H1 immediately, even before the async data arrives.
</p>
</main>
</div>
<script>
// React streaming inline data
(self.__next_f=self.__next_f||[]).push([0,"This data came from the server!"]);
</script>
</body>
</html>
More about rendering strategies
Now that we have seen how streaming works, let's talk about the different strategies that emerged from this evolution of JavaScript on the server. Each approach represents a different way of thinking about when and where to execute your JavaScript:
| Strategy | When JavaScript Runs | Use Case | Frameworks |
|---|---|---|---|
| SSR | Server renders React components on each request, then hydrates on client | Perfect for dynamic content, real-time data, and SEO-critical pages... this is what Nextjs was built for | ⚛️ Next.js, 🟢 Nuxt, 🟠 SvelteKit, 🎯 Remix, 🔷 SolidStart |
| SSG | JavaScript runs at build time to pre-generate static HTML files | Ideal for blogs, documentation, marketing pages that rarely change, like this page right here :D | ⚛️ Next.js, 🟢 Nuxt, 🟠 SvelteKit, 🚀 Astro, ⚡ Gatsby, 📚 VitePress |
| ISR | Build-time generation + on-demand revalidation when data changes | E-commerce product pages, news sites - fast static with fresh data updates | ⚛️ Next.js (pioneer), 🟢 Nuxt, 🟠 SvelteKit |
| CSR | Client-side rendering - JavaScript runs entirely in the browser | SPAs, dashboards, admin panels where SEO isn't critical | ⚛️ React, 🟢 Vue, 🟠 Svelte, 🔴 Angular, 🎨 HTMX + Alpine.js |
| Streaming | Server streams HTML progressively as components finish rendering | Large pages with slow data fetches - show content as it becomes available | ⚛️ Next.js (App Router), 🎯 Remix, 🟠 SvelteKit, 🔷 SolidStart |
| Resumability | Server serializes component state, client resumes from exact point | Qwik's approach - instant hydration without re-executing server work | ⚡ Qwik (exclusive), 🏙️ Qwik City |
| Islands | Interactive islands hydrate independently on static HTML pages | Astro, Fresh - mostly static sites with selective interactivity | 🚀 Astro (pioneer), 🦕 Fresh, 🎨 Marko, 🔮 Enso |
| SSI | Server inserts dynamic content into static HTML using server directives | Great for adding dynamic headers/footers to otherwise static content | 🟢 Nginx, 🔴 Apache, ☁️ Cloudflare Workers, 🎨 HTMX |
| SSR + SSG | Hybrid: Static pages for content, SSR for dynamic user-specific pages | E-commerce sites: static product pages + dynamic user dashboards | ⚛️ Next.js, 🟢 Nuxt, 🟠 SvelteKit, 🎯 Remix |
Note that these are the strategies that come off the top of my ming , there can be many other , but that's just to mention where javascript actually runs, nothing else.
Jamie Turner
Evan You
Let's talk about Bundlers now :)
