FSM Full Stack Masterclass
Platform under construction
JavaScript course badge

Versions & Runtimes

Intermediate

Browser, Node, Deno & Bun

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

A runtime is the world your JavaScript lives inside.

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.

Browser

Best for user interface behavior: DOM, events, forms, animation, storage and web APIs.

Node.js

Established server runtime with a huge ecosystem, npm packages and built-in server APIs.

Deno

Modern runtime with secure defaults, TypeScript-first workflow and built-in tooling.

Bun

All-in-one toolkit aiming for fast runtime, package management, testing and bundling.

Examples

Good JavaScript respects its target environment.

Runtime-aware code

function getRuntimeName() {
  if (typeof window !== "undefined") {
    return "browser";
  }

  if (typeof process !== "undefined") {
    return "server runtime";
  }

  return "unknown";
}

Browser code pasted into server code

// 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

Version and runtime choices are production decisions.

Modern JavaScript is powerful, but support is never automatic. Choose syntax, APIs and tooling based on the environments that must run the code.

Know the globals

window and document are browser globals. process and node:fs are server-side concepts.

Do not assume package compatibility

A package may depend on Node-specific APIs and fail in a browser or different runtime.

Choose by project needs

Use the runtime that matches hosting, libraries, team experience and production requirements.

Respect security models

Deno-style permissions, server secrets and browser sandbox rules all change how code should be written.

Test in the real runtime

Passing in one runtime does not prove another runtime behaves the same.

Keep shared code pure

Code shared between browser and server should avoid runtime-specific APIs where possible.

Production thinking

Support strategy keeps modern JavaScript reliable.

Why does this matter?

Runtime awareness is what stops beginners from asking why document is undefined in Node or why node:fs cannot run in the browser.

Accessibility

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 note

Production runtime choice affects deployment, monitoring, package management, security updates, performance and team workflow.

SEO note

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

Change the HTML, CSS or JavaScript and run the result.

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

Try this now.

  • Change the message for browser runtime.
  • Add a second check for localStorage.
  • Write a comment that explains why document is browser-specific.

Practice assignment

Do this before moving to the next topic.

  1. List three browser-only globals or APIs.
  2. List three server-runtime concepts.
  3. Explain why one JavaScript file may not run everywhere.

Try it yourself

Detect the current runtime safely

Live preview

Self-check

Before you continue, prove that you understand Browser, Node, Deno & Bun.

Intermediate

Answer these questions before moving on. Versions and runtimes look theoretical until they break a real page.

  1. Can you define a JavaScript runtime?
  2. Can you explain why document exists in the browser but not in Node by default?
  3. Can you name one strength of Node.js, Deno and Bun?
  4. Can you explain why runtime choice affects production?
  5. Can you identify code that is safe to share across runtimes?

Chapter checkpoint

Versions & Runtimes checkpoint

Finish this chapter by turning the lessons into a small practical proof.

Build

Create a short support note for a project that names target browsers, Node version and polyfill policy.

Deliverables

  • runtime list
  • feature-support note
  • fallback or upgrade decision

Quality checks

  • ECMAScript and browser APIs separated
  • experimental features marked
  • links to reference sources

Review question

Would another developer know whether a modern feature is safe to use?