Browser
Best for user interface behavior: DOM, events, forms, animation, storage and web APIs.
JavaScript can run in browsers and server runtimes, but each environment provides different globals, APIs, module rules and production tradeoffs.
// Browser
console.log(window.location.href);
// Node.js / server runtime
import { readFile } from "node:fs/promises";
Versions & Runtimes
ECMAScript defines the language, but code needs a runtime to do useful work. A browser runtime gives access to the DOM, window, events, storage, fetch and web APIs. A server runtime gives access to files, network servers, environment variables and packages.
Node.js is the established server-side JavaScript runtime. Deno focuses on secure defaults, TypeScript support and a built-in toolchain. Bun positions itself as an all-in-one JavaScript toolkit with runtime, package manager, test runner and bundler.
None of this means one runtime is automatically best for every project. The right choice depends on hosting, ecosystem, compatibility, team knowledge, security model, tooling and what the project actually has to do.
Best for user interface behavior: DOM, events, forms, animation, storage and web APIs.
Established server runtime with a huge ecosystem, npm packages and built-in server APIs.
Modern runtime with secure defaults, TypeScript-first workflow and built-in tooling.
All-in-one toolkit aiming for fast runtime, package management, testing and bundling.
Examples
function getRuntimeName() {
if (typeof window !== "undefined") {
return "browser";
}
if (typeof process !== "undefined") {
return "server runtime";
}
return "unknown";
}
// This fails in many server runtimes because document is a browser global.
const title = document.querySelector("h1").textContent;
// This fails in the browser because node:fs is a server module.
import { readFileSync } from "node:fs";
Rules that matter
Modern JavaScript is powerful, but support is never automatic. Choose syntax, APIs and tooling based on the environments that must run the code.
window and document are browser globals. process and node:fs are server-side concepts.
A package may depend on Node-specific APIs and fail in a browser or different runtime.
Use the runtime that matches hosting, libraries, team experience and production requirements.
Deno-style permissions, server secrets and browser sandbox rules all change how code should be written.
Passing in one runtime does not prove another runtime behaves the same.
Code shared between browser and server should avoid runtime-specific APIs where possible.
Production thinking
Runtime awareness is what stops beginners from asking why document is undefined in Node or why node:fs cannot run in the browser.
Browser runtime code directly affects user interaction. Server runtime code can affect rendered HTML, performance and reliability before the user even sees the page.
Production runtime choice affects deployment, monitoring, package management, security updates, performance and team workflow.
Server rendering, static rendering and client rendering all depend on runtime decisions. Choose an approach that leaves important content and links discoverable.
Live code lab
The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.
Mini assignment
Practice assignment
Try it yourself
Self-check
Answer these questions before moving on. Versions and runtimes look theoretical until they break a real page.
Chapter checkpoint
Finish this chapter by turning the lessons into a small practical proof.
Create a short support note for a project that names target browsers, Node version and polyfill policy.
Would another developer know whether a modern feature is safe to use?