Beyond the browser: Node.js, Deno & Bun

Beyond the browser

Earlier lessons separated the JavaScript language from the host that runs it. In Engines, runtimes & hosts, you learned that V8, SpiderMonkey, and JavaScriptCore run language features while a host provides APIs. In Runtime overview, you connected engines, host APIs, queues, and the event loop. This lesson builds on that map and asks a professional question: what changes when JavaScript leaves a browser page?

Keep one rule in mind: Node-only code is not browser code. The lesson marks Node, Deno, Bun, and shell examples as non-runnable in the page. The tests run the Node snippets with real Node instead of pretending the browser can do it.

Node.js is not a different language. It is JavaScript running in a server and tooling runtime: V8 runs the language, libuv helps with evented I/O, built-in modules expose operating-system features, and the npm ecosystem supplies packages. The upcoming npm & package.json lesson goes deeper into package installation and scripts.

Plain Node does not give you window, document, or DOM elements. Use globalThis for the global object name that also works in browsers and modern server runtimes. Use process for Node-specific process information.

This Node-only script reads command-line data, writes and reads a file, joins paths safely, inspects the OS, and sets process.exitCode. It is marked non-runnable because the in-page editor is a browser sandbox, not Node.

1import { readFile, writeFile } from "node:fs/promises";2import path from "node:path";3import os from "node:os";4 5process.env.RUNTIME_LESSON = "Node.js";6const name = process.argv[1] ?? "friend";7const file = path.join(process.cwd(), "message.txt");8 9await writeFile(file, `Hello ${name} from ${process.env.RUNTIME_LESSON}`);10const text = await readFile(file, "utf8");11process.exitCode = text.includes(name) ? 0 : 1;12 13console.log(path.basename(file));14console.log(text);15console.log(os.platform().length > 0);

Line 1 imports promise-based file helpers. Line 2 uses path.join so the script works on different operating systems. Line 6 reads the first user argument from process.argv. Line 11 sets the exit code but lets the script finish naturally.

1// ECMAScript module2import { readFile } from "node:fs/promises";3export async function loadConfig(file) {4  return JSON.parse(await readFile(file, "utf8"));5}6 7// CommonJS module8const { readFileSync } = require("node:fs");9module.exports.loadConfigSync = (file) => {10  return JSON.parse(readFileSync(file, "utf8"));11};

Modern Node supports ECMAScript modules with import and export, and it still supports CommonJS with require and module.exports. The CommonJS & ESM lesson covers package settings, extensions, and migration details.

Runtime code often starts as a command-line tool. Node gives a script an argument array, environment variables, a current working directory, and a way to report success or failure. The parser below deliberately avoids Node APIs so you can step through it in the browser, then reuse the same logic with process.argv.slice(2) in Node.

1function parseArgs(argv) {Run2  const options = { _: [] };3  for (const token of argv) {4    if (token.startsWith("--")) {5      const [key, value = "true"] = token.slice(2).split("=");6      options[key] = value;7    } else {8      options._.push(token);9    }10  }11  return options;12}13 14const parsed = parseArgs(["build", "--watch", "--out=dist"]);15console.log(JSON.stringify(parsed));

1function parseArgs(argv) {2  const options = { _: [] };3  for (const token of argv) {4    if (token.startsWith("--")) {5      const [key, value = "true"] = token.slice(2).split("=");6      options[key] = value;7    } else {8      options._.push(token);9    }10  }11  return options;12}13 14const parsed = parseArgs(["build", "--watch", "--out=dist"]);15console.log(JSON.stringify(parsed));

File APIs are fine for small config files, but large logs, uploads, and responses should be streamed. Streams let a program process chunks gradually instead of loading everything into memory at once. The Streams & progress lesson teaches browser streams in depth; Node also has classic streams and web streams.

1import { createReadStream } from "node:fs";2import { writeFile } from "node:fs/promises";3import path from "node:path";4 5const file = path.join(process.cwd(), "access.log");6await writeFile(file, "GET /a\nGET /b\nGET /c\n");7 8let chunks = 0;9let characters = 0;10for await (const chunk of createReadStream(file, { encoding: "utf8", highWaterMark: 8 })) {11  chunks += 1;12  characters += chunk.length;13}14 15console.log(`${chunks} chunks`);16console.log(`${characters} characters`);

Line 10 starts reading the file in small chunks. The loop body updates counters for each chunk. In production, the body might parse a CSV row, update a hash, or stream data to an HTTP response.

1import { spawnSync } from "node:child_process";2import { createHash } from "node:crypto";3import http from "node:http";4 5const digest = createHash("sha256").update("runtimes").digest("hex").slice(0, 8);6const child = spawnSync(process.execPath, ["-e", "process.exitCode = 7"]);7const server = http.createServer((request, response) => {8  response.end(`ok ${request.url}`);9});10 11await new Promise((resolve) => server.listen(0, "127.0.0.1", resolve));12const address = server.address();13const body = await new Promise((resolve, reject) => {14  http.get({ host: "127.0.0.1", port: address.port, path: "/health" }, (response) => {15    let data = "";16    response.setEncoding("utf8");17    response.on("data", (chunk) => { data += chunk; });18    response.on("end", () => resolve(data));19  }).on("error", reject);20});21await new Promise((resolve) => server.close(resolve));22 23console.log(digest);24console.log(child.status);25console.log(body);

Line 6 starts a child Node process and reads its exit status. Lines 7 through 21 create a tiny HTTP server and make one request to it. Line 5 uses classic Node crypto; the common API section compares that with Web Crypto.

Deno and Bun are not installed in this workspace, so the lesson does not display fake command output or benchmark numbers. The commands below are shown as reference shapes and are verified against current official documentation in the lesson research.

Deno: secure by default and web-aligned

Deno uses V8, starts with sensitive permissions disabled, runs TypeScript without a separate project setup, supports web APIs, can import npm packages with npm: specifiers, and uses deno.json or deno.jsonc for project tasks and settings. File, network, environment, and subprocess access require explicit permission flags such as --allow-read or --allow-net.

1deno run main.ts2deno run --allow-read=./data main.ts3deno run --allow-net=api.example.com server.ts4deno run -A trusted-tool.ts

1{2  "tasks": {3    "start": "run --allow-read=./data --allow-net=api.example.com main.ts"4  },5  "imports": {6    "@std/path": "jsr:@std/path",7    "chalk": "npm:chalk@^5.0.0"8  },9  "compilerOptions": {10    "strict": true11  }12}

Bun: JavaScriptCore and an all-in-one toolchain

Bun uses JavaScriptCore, the same JavaScript engine family as Safari. Its project is an all-in-one runtime, package manager, bundler, and test runner with ongoing Node compatibility work. Use this fact, not copied benchmark claims, when deciding whether Bun is a good fit for a team.

1bun run index.ts2bun test3bun build ./src/app.ts --outdir=dist4bun add zod

Edge platforms such as Cloudflare Workers, Vercel Edge Functions, Netlify Edge Functions, and Deno Deploy run code near users. Instead of a long-lived local process with full file access, they usually run small request handlers in isolate-style environments. The handler receives a Request and returns a Response.

1function handleRequest(request) {Run2  const url = new URL(request.url);3  if (url.pathname === "/api/greet") {4    const name = url.searchParams.get("name") || "friend";5    return Response.json({ message: `Hello ${name}` }, {6      headers: { "x-runtime": "web-compatible" },7    });8  }9  return new Response("Not found", { status: 404 });10}11 12const request = new Request("https://lesson.test/api/greet?name=Ada");13const response = handleRequest(request);14console.log(response.status);15console.log(response.headers.get("x-runtime"));

1function handleRequest(request) {2  const url = new URL(request.url);3  if (url.pathname === "/api/greet") {4    const name = url.searchParams.get("name") || "friend";5    return Response.json({ message: `Hello ${name}` }, {6      headers: { "x-runtime": "web-compatible" },7    });8  }9  return new Response("Not found", { status: 404 });10}11 12const request = new Request("https://lesson.test/api/greet?name=Ada");13const response = handleRequest(request);14console.log(response.status);15console.log(response.headers.get("x-runtime"));

Edge code is intentionally constrained. You should expect CPU and memory limits, no local file system, no child processes, and no full Node core-module surface. Exact limits vary by platform and plan, so production code should keep work short, stream when possible, and use platform storage bindings instead of local disk.

1export default {2  fetch(request, env, ctx) {3    return handleRequest(request);4  },5};6 7function handleRequest(request) {8  const country = request.headers.get("cf-ipcountry") || "unknown";9  return new Response(`Hello ${country}`, {10    headers: { "content-type": "text/plain" },11  });12}

This entry point looks like Cloudflare Worker style code: the platform calls fetch, your code returns a Response, and platform-specific data arrives through request headers or bindings such as env. The pure handler above keeps business logic portable.

Modern runtimes share more APIs than they used to. The portable surface includes fetch, Request, Response, Headers, URL, URLSearchParams, Web Streams, TextEncoder, Web Crypto APIs such as crypto.subtle and crypto.randomUUID, structuredClone, AbortController, setTimeout, and EventTarget.

The standards effort is now called WinterTC, Ecma Technical Committee 55. It was formerly the WinterCG community group. Its Minimum Common API work has an Ecma standard snapshot, ECMA-429, so server runtimes have a concrete web-compatible baseline to aim at.

1const request = new Request("https://lesson.test/search?q=edge");2const url = new URL(request.url);3const bytes = new TextEncoder().encode(url.searchParams.get("q"));4const copy = structuredClone({ q: url.searchParams.get("q"), bytes: bytes.length });5const response = new Response("ok", { headers: new Headers({ "x-api": "fetch" }) });6const stream = response.body;7const controller = new AbortController();8const target = new EventTarget();9let heard = false;10target.addEventListener("done", () => { heard = true; });11target.dispatchEvent(new Event("done"));12 13console.log(`${copy.q}:${copy.bytes}:${response.headers.get("x-api")}`);14console.log(stream instanceof ReadableStream);15console.log(typeof crypto.subtle?.digest);16console.log(crypto.randomUUID().length === 36);17console.log(controller.signal.aborted);18console.log(heard && typeof setTimeout === "function" && typeof fetch === "function");

Where you’ll use runtime knowledge

Professional JavaScript often crosses runtime boundaries. Build tools and CLIs run in Node, Deno, or Bun. Web apps run in browsers. API routes may run in Node serverless functions or edge isolates. Packages may publish one entry point for browsers and another for Node.

• CLIs: read process.argv, validate flags, set process.exitCode, and stream output.
• Build tools: read project files, spawn compilers, hash assets, and write bundles.
• APIs: use Node http or framework adapters for long-running server code.
• Edge personalization: inspect a Request, read a platform binding, and return a small Response quickly.
• Portable utilities: prefer URL, Request, Web Streams, and Web Crypto when the code should travel.

Common misconceptions

• “JavaScript outside the browser can use the DOM.” The DOM is a browser page API. Server runtimes can parse HTML with libraries, but they do not have a real page by default.
• “Node built-ins are standard JavaScript.” Names like fs, path, and child_process are Node host APIs.
• “Deno and Bun are just Node with new commands.” They make different choices around permissions, engines, tooling, and compatibility.
• “Edge means unlimited server close to the user.” Edge code is close to users but constrained by CPU, memory, API, and platform limits.
• “If an API is web-compatible, behavior is identical everywhere.” The shape travels, but host policies and limits still matter.

Key takeaways

• Node.js is V8 plus libuv, built-in modules, process access, and npm ecosystem tooling; it is not a browser page.
• Use process.argv, process.env, and process.exitCode for CLI behavior, and streams for large data.
• Deno emphasizes secure permissions, built-in TypeScript, web APIs, npm: imports, and deno.json.
• Bun uses JavaScriptCore and combines runtime, package manager, bundler, and test runner ideas with Node compatibility work.
• Edge runtimes favor small Request to Response handlers, web APIs, platform bindings, and strict limits.
• The common web API surface is the best starting point for code that should move between browsers, Node, Deno, Bun, and edge.

Up next: Unit testing.