Client vs server-side code, and why the difference matters more than the language.

Section · 01

The two halves of a web app

Every web app has code in two places:

CLIENT side                    SERVER side
─────────────                  ─────────────
Runs in the user's browser     Runs on your machine
HTML, CSS, JavaScript          Anything — Node, Python, Go, PHP, Rust, ...
Anyone can read it             Only you can read it
Can't be trusted               Can be trusted (with caveats)
Talks to the server via fetch  Talks to the database, file system, other services
~10s of MB available           ~GB of RAM available

The line between them is the network. Code on the client side is shipped — anyone with DevTools can read it. Code on the server stays on your machine and only its outputs cross the wire.

Section · 02

Why this matters: secrets

// CLIENT CODE — yorksims.com/app.js
const STRIPE_SECRET_KEY = "sk_live_8jZ...";  // EVERY visitor sees this. You just leaked your account.
const DB_PASSWORD = "hunter2";                // Same. Disaster.

const STRIPE_PUBLISHABLE_KEY = "pk_live_8jZ..."; // OK — pub keys are designed to be public.

API keys, database passwords, signing secrets — anything that gives access to a system — never go in client code. The rule is mechanical: anything that runs in the browser will be read by an attacker. Bundlers don’t change that. Minification doesn’t change that. Variable names don’t change that. If the browser can run it, the browser can leak it.

Section · 03

Server-side languages — what each is for in 2026

Node.js / TypeScript    — same language as the client; popular for web APIs
Python                  — data, ML, scripting, internal tools, increasingly web (FastAPI)
Go                      — high-throughput services, CLI tools, infrastructure
Rust                    — performance-critical, embedded, infra
PHP                     — still 40%+ of the web (WordPress); Laravel is excellent
Ruby                    — Rails; mature ecosystem, smaller community than it was
Java / Kotlin           — large enterprise backends, Android
C#                      — Microsoft stack, gaming (Unity), enterprise

For a new web project the realistic short list is Node/TS, Python, or Go. Pick what you know. The framework choice (Next.js, Django, Express, FastAPI, Rails) matters more than the language for most teams.

Section · 04

Rendering models — SSR, CSR, SSG

Where HTML gets generated is a choice with real consequences:

SSG — Static Site Generation
  Build time. HTML is pre-rendered into files.
  Pros: fastest possible; ship cheaply to a CDN.
  Cons: needs rebuild on content change.
  Use: blogs, docs, marketing pages.

SSR — Server-Side Rendering
  Request time. Server runs code, returns HTML.
  Pros: fresh per request; user-specific content; great SEO.
  Cons: server cost per request.
  Use: dashboards, e-commerce, anything personalized.

CSR — Client-Side Rendering
  Request time, in the browser. Server returns empty HTML + JS bundle; JS builds the page.
  Pros: SPA feel, no full page loads.
  Cons: slow first paint, SEO problems, runs the user's CPU.
  Use: web apps where SEO doesn't matter (admin UIs, internal tools).

Modern frameworks (Next.js, Astro, SvelteKit) let you pick per-page. This site renders the marketing pages statically and dashboard pages on the server.

Section · 05

Serverless functions

Serverlessis a deployment model where you write small functions and let a provider (Vercel, AWS Lambda, Cloudflare Workers) run them on demand. No server to manage, billed per request. Cold starts are a concern; long-running tasks aren’t a great fit.

// app/api/hello/route.ts  (Next.js example)
export async function GET(request) {
  return new Response(JSON.stringify({ hi: "there" }), {
    headers: { "Content-Type": "application/json" },
  });
}

For most modern web projects the realistic stack is: Next.js (or similar) handling both server rendering and API routes, deployed to Vercel/Netlify/Cloudflare, with a managed database (Neon, Supabase, PlanetScale).

Section · 06

A worked example: PHP, the classic server language

Most of the older internet runs on PHP. WordPress alone is 40% of the web. It’s worth seeing what server-side code looks like outside of JavaScript.

<!-- contact.php -->
<?php
if ($_SERVER["REQUEST_METHOD"] === "POST") {
    $name = $_POST["name"] ?? "";
    $email = $_POST["email"] ?? "";

    // Save to database (pseudo)
    saveContact($name, $email);

    echo "<p>Thanks, $name. We'll email you at $email.</p>";
}
?>

<form method="post">
  <input name="name" required />
  <input name="email" type="email" required />
  <button type="submit">Submit</button>
</form>

PHP literally mixes HTML and code in one file. The <?php ... ?> blocks run on the server; everything outside runs as plain HTML. Modern PHP (Laravel, Symfony) uses templating and routing instead, but the underlying model is the same.

Section · 07

The takeaway

Three rules:

1. Secrets stay on the server. Always.
2. Validate user input on the server. Client validation is for UX, not security.
3. The right amount of client-side code is the minimum that gives users a snappy UX.
   Everything else belongs on the server.

Next lesson: where data lives between requests — cookies, sessions, and the browser’s storage APIs.