Most introductions to JavaScript skip the question of what JavaScript actually is. They jump straight into console.log('Hello') and leave you with a shaky model of what is happening when you press Run. This lesson does the opposite. We spend a few paragraphs on the parts that almost no tutorial explains carefully — what a language even is, what an engine does with your code, and why JavaScript happens to run in so many places now.

If you have ever wondered why the same JavaScript can power a button in your browser, a CLI on your laptop, a serverless function in the cloud, and a smart-speaker app — by the end of this lesson you will know exactly why.

JavaScript is a language. ECMAScript is the spec. #

The word JavaScript refers to a programming language. The word ECMAScript refers to the formal written specification of that language. They are not quite synonyms.

• The ECMAScript specification is a document maintained by a standards committee called TC39. It defines the syntax (if, function, =>), the semantics (what + does to a string vs. a number), and the built-in objects (Array, Map, Promise).
• An implementation is a piece of software that reads source code and runs it according to that spec. V8 (Google), SpiderMonkey (Mozilla), JavaScriptCore (Apple), and ChakraCore (legacy Microsoft) are the four major ones.
• A runtime is the implementation plus everything it ships with (built-in libraries, I/O, scheduling). Node.js is a runtime built on V8. The browser is a runtime built on whatever engine the browser ships.

The spec gets a new edition every year — ES2015, ES2024, ES2025, and so on. Each edition adds features (async/await, optional chaining, using declarations). The implementations race to ship them. "JavaScript" colloquially refers to whatever the latest implementations are capable of.

When you see let x = 1 in your editor, your editor is showing you JavaScript. When V8 reads those four tokens and executes them, V8 is following the ECMAScript spec. The two words point at the same thing from different angles.

The engine is not the runtime #

This is the most common confusion. "The engine" and "the runtime" sound interchangeable, but they are different.

V8 by itself does not know what setTimeout is. It does not know what fetch is. It does not know what document is. Those come from the host. The engine just speaks the language.

This is why the same engine can show up in wildly different runtimes. V8 powers Chrome (which gives it the DOM and fetch), Node.js (which gives it fs and http), and Cloudflare Workers (which gives it a request handler and KV storage). Same engine. Different hosts. Different capabilities.

Where JavaScript runs today #

In 2026, "places JavaScript runs" is a longer list than most languages can claim. Here are the ones you will actually encounter.

1. The browser #

The original home. Every modern browser ships with a JavaScript engine and exposes a host environment that includes:

• The DOM (document.getElementById, addEventListener)
• Web APIs (fetch, localStorage, IndexedDB, WebSocket, Notification)
• Worker contexts (Worker, ServiceWorker, SharedWorker) for off-main-thread code
• A single-threaded event loop orchestrating it all

In the browser, JavaScript reaches the engine via <script> tags or as import-resolved module graphs. The engine parses, compiles, and runs it inside a sandbox tied to the page's origin.

2. Node.js #

Node.js is V8 plus a C++ layer that gives JavaScript access to the operating system. Files (fs), network sockets (net, http), child processes (child_process), and a richer event loop based on libuv.

Node is how JavaScript escaped the browser. It is what makes tooling like Vite, esbuild, Webpack, and TypeScript possible — all of them are JavaScript programs running outside a browser, reading and writing files.

3. Deno and Bun #

Newer runtimes that compete with Node:

• Deno also uses V8, but ships with a different standard library, native TypeScript support, secure-by-default permissions, and Web-API-like primitives (fetch, Request, Response) instead of Node's older APIs.
• Bun uses JavaScriptCore (Apple's engine) instead of V8 and aims to be a drop-in faster Node replacement with built-in transpilation, a package manager, and a test runner.

If you start a new server project in 2026, you choose between Node, Deno, and Bun based on ecosystem maturity, performance, and ergonomics — not on what language you want to write.

4. Serverless and edge runtimes #

• AWS Lambda, Google Cloud Functions, and Azure Functions run Node-compatible JavaScript on demand
• Cloudflare Workers runs V8 isolates at the edge — your code starts in single-digit milliseconds because there is no full Node process
• Vercel Edge Functions, Netlify Edge — similar story, optimized for short-lived request handlers

These environments give you a subset of Node or a Web-API-shaped host. Knowing which subset is the daily reality of working with them.

5. Embedded JavaScript #

Less famous but useful to know about:

• Electron wraps Node + Chromium so desktop apps (VS Code, Slack, Discord) can be built in JavaScript
• React Native runs JavaScript on phones, talking to native iOS / Android APIs
• Smart TVs and set-top boxes often run web apps via embedded WebKit or Chromium
• MongoDB, CouchDB, and a few other databases let you write stored procedures in JavaScript via embedded V8

If the device has a screen and an internet connection, there is a non-zero chance some part of it is JavaScript.

What this means in practice #

The practical lesson is this: the language is small, the host is everything.

When you read documentation, when you ask "why doesn't this work," when you wonder whether some API is available — the answer almost always lives at the host layer, not the language layer.

// Pure language — works in every host
const nums = [1, 2, 3];
const doubled = nums.map(n => n * 2);
console.log(doubled); // [2, 4, 6]

// Host APIs — only in browsers
document.title = 'Hello'; // breaks in Node — `document` doesn't exist
await fetch('/api/users'); // works in modern browsers, Deno, Bun, Node 18+

// Host APIs — only in Node
import fs from 'node:fs/promises';
await fs.writeFile('out.txt', 'hi'); // breaks in browsers — no filesystem

When something works in one environment and fails in another, it is almost never the language. It is the host's API surface.

A tour of one line of code, in two hosts #

Let's trace what happens to console.log('hello') so the engine-vs-host split becomes concrete.

In the browser:

1. You write <script>console.log('hello')</script> in an HTML file.
2. The browser's HTML parser encounters the script tag and hands the body to the JavaScript engine.
3. The engine parses the source into an AST, compiles it, and executes it.
4. The engine evaluates console.log by looking it up on the global object. The global object is window in the browser.
5. window.console is provided by the browser, not by the engine. It is a host-provided object.
6. window.console.log is called with 'hello'. The browser's implementation pushes the string into the DevTools console.

In Node.js:

1. You write console.log('hello') in app.js and run node app.js.
2. Node spins up V8 and hands it the file contents.
3. V8 parses, compiles, and executes — same as the browser. The engine layer is identical.
4. The engine evaluates console.log by looking it up on the global object. In Node the global object is globalThis (or global).
5. globalThis.console is provided by Node, not by V8.
6. globalThis.console.log is called with 'hello'. Node's implementation writes to stdout.

Same engine. Same language. Different host. Different visible effect.

How code becomes a running program #

The high-level pipeline is the same in every modern engine:

1. Source — your .js file, or the contents of a <script> tag
2. Parse — tokenize, build an Abstract Syntax Tree (AST)
3. Compile — translate the AST into bytecode and then JIT into machine code
4. Execute — run the machine code; on hot loops, re-optimize with type feedback
5. Garbage collect — periodically reclaim memory the program no longer references

The details vary by engine — V8 has Ignition (bytecode interpreter) and TurboFan (optimizing compiler), SpiderMonkey has Baseline and IonMonkey — but the shape is universal.

For everyday work, the only step you usually care about is execute. The rest happens beneath you. We come back to the call stack, the heap, and garbage collection in Module 6.

Why this matters for the rest of the tutorial #

Every lesson from here on assumes you know:

• JavaScript is the language; ECMAScript is its spec.
• An engine runs the language; a host gives the engine APIs.
• The same JavaScript can run almost anywhere, but the available APIs change with the host.

When a future lesson says "in the browser, the event loop also processes rAF callbacks," or "in Node, top-level await works in ESM but not CJS," you will know those statements are about the host, not the language.

When documentation says "this works in Node 18+ and modern browsers," you will know it is talking about which hosts have shipped the relevant host API or language feature yet.

This framing — language vs. engine vs. host — is the lens through which everything else makes sense.

What's next #

Lesson 1.2 covers variables — the three ways to declare them (let, const, var), the differences in scoping and hoisting, and the rules of thumb that hold across every modern JavaScript codebase. Once you know what a variable is and where it lives, every other concept in the language starts to slot into place.

Try it yourself #

Open any modern AI assistant that can run JavaScript and ask it which host it's running in. The answer reveals more than you'd expect.

Three typeof checks, three different hosts pinned down. That is the whole engine-vs-host model in a one-line probe.