JavaScript#

JavaScript (JS) is the only programming language that runs natively inside browsers. It was created in 1995 by Brendan Eich at Netscape — famously in just 10 days under competitive pressure from Microsoft. The rushed design left permanent quirks in the language that persist to this day.

Note

The name is pure marketing. JavaScript has almost nothing to do with Java — it borrowed more from Scheme and Self. Netscape named it “JavaScript” to ride Java’s hype in 1995.

Origin and the Browser Wars#

Early browsers were document viewers. Every interaction — a form submission, a button click — required a full round trip to the server and a complete page reload. Netscape wanted a lightweight scripting language that could make pages interactive without reloading. They hired Eich and told him to build one fast.

Microsoft responded by cloning JavaScript into JScript, their own implementation shipped in Internet Explorer 3 (1996). To avoid trademark issues they changed the name just enough — not the behavior. This kicked off years of cross-browser compatibility hell: the same JS code behaved differently in IE vs Netscape.

To avoid chaos, the industry agreed on a language specification called ECMAScript. The implementations (V8, SpiderMonkey, JavaScriptCore) remained separate and competitive, but the language rules became standardized.

The Sandbox Model#

When a browser loads a page, it fetches the HTML, finds <script> tags, downloads those JS files, and hands them to its JS engine to execute. That execution happens on the user’s machine, inside a strict sandbox:

JS can manipulate the page (DOM), make network requests, read cookies
JS cannot access the filesystem, open system ports, or read environment variables

The sandbox is enforced at the API level — filesystem functions simply don’t exist in the browser environment. There is no list_files() to call. The browser only exposes what it deliberately chooses to expose.

This is why malicious websites can’t just run arbitrary code and destroy your machine, and it’s also why Node.js had to be invented.

Client-Side vs Server-Side#

For most of the web’s history, servers did the heavy lifting: building complete HTML pages and sending them to the browser. The browser just rendered them. JS was a thin layer for small interactions.

The modern React era shifted much of that work to the client. The server sends a minimal HTML file and a large JS bundle; the browser downloads it, executes it, and builds the entire page. This is client-side rendering (CSR).

The tradeoff is real: JS executes on the user’s hardware. A demanding app can slow down or freeze on low-end devices. This is why the industry is gradually shifting back toward a hybrid model — frameworks like Next.js server-render the initial page for speed, then hydrate it client-side for interactivity.

Multiple Runtimes#

Because each browser vendor built their own JS engine independently, there are several mainstream implementations:

V8 — Chrome, Edge, Node.js (Google)
SpiderMonkey — Firefox (Mozilla)
JavaScriptCore — Safari (Apple)

They all implement the ECMAScript spec, but they are entirely separate codebases. Competition between them is largely why JS performance improved so dramatically between 2008 and 2015.

On the server and tooling side, V8 (via Node.js) effectively won — nobody runs SpiderMonkey to execute build tools. The fragmentation only persists where browsers are involved.

TypeScript#

Because raw JS has no type system and is error-prone at scale, TypeScript (TS) was created by Microsoft as a typed superset of JS. You write TS, a compiler checks your types, and outputs plain JS. TypeScript never runs anywhere — it always compiles away before execution.

This is a recurring pattern in the JS ecosystem: write in one language, compile to JS that the browser actually executes.