Manuals and specifications

This course is a tutorial. Its job is to walk you into the language one idea at a time, in an order that makes sense while you’re still forming a mental model. That’s exactly what you want early on.

It’s also the wrong shape for later. Once the basics click, your questions stop being “how do I loop over an array?” and turn into “what are all the arguments Array.prototype.slice accepts, and what does a negative index do?” A tutorial can’t answer that for every method — it would be ten thousand pages and nobody would read it. For those questions you reach for a different kind of resource: a reference, a spec, or a support table.

Here’s the map of what exists and when to open each one.

Specification

The ECMA-262 specification is the document that defines JavaScript. When people argue about how some corner of the language behaves, this is the text that settles it. Every engine — the one in your browser, the one in Node.js, the one in Deno — is an attempt to implement exactly what this document describes.

Because it’s a formal specification, it reads like one. It’s written for people building JavaScript engines, not for people writing JavaScript. Open it expecting pseudocode-flavored algorithms, numbered steps, and prose like “Let O be ? ToObject(this value).” That precision is the whole point: there’s no room for “you know what I mean.” But it also means the spec is a terrible place to learn anything, and a great place to confirm a detail you can’t pin down anywhere else.

A fresh version of the specification ships once a year. Between those yearly releases, the work-in-progress draft lives at https://tc39.es/ecma262/ — that’s usually the link you want, since it reflects the current state of the language rather than last year’s snapshot.

Peeking at what’s next

New language features don’t appear out of nowhere. They move through a staged proposal process run by TC39, the committee that stewards the language. A proposal climbs from stage 0 (rough idea) up to stage 4 (shipped, part of the standard). By the time something reaches stage 3, it’s close to final and engines often start shipping it experimentally.

You can browse every proposal and its current stage at https://github.com/tc39/proposals. It’s a good bookmark if you like knowing what the language is about to gain.

If your target is the browser specifically, there’s a whole second family of specifications — the DOM, fetch, events, and so on — that describe the environment around the language rather than the language itself. Those get their own treatment in the browser part of this course.

Manuals

For day-to-day work, the reference you’ll actually keep open is MDN (Mozilla Developer Network) JavaScript Reference. Each language function, method, and object gets its own page with a description, the full parameter list, return values, edge-case notes, browser support, and — the part that saves you — runnable examples. It’s written for developers, so it explains things instead of just specifying them.

Find it at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference.

In practice, though, most people never navigate MDN by hand. It’s faster to search. Type the method name with MDN in front of it and let your search engine jump you straight to the right page:

So a search for MDN parseInt lands you on the parseInt reference in one hop. Works for anything: MDN Array.map, MDN Promise.all, MDN String.replace.

Compatibility tables

JavaScript keeps growing. New syntax and new methods land every year, but the engines that run your code update on their own schedules — and your users are spread across a long tail of browser versions you don’t control. So a feature existing in the spec doesn’t mean it runs on the phone in someone’s pocket. You need a way to check.

The two overlap but lean different ways. caniuse is organized around a feature you have in mind and answers “can I use it?” — it also covers browser APIs, not just the language. compat-table is organized around the engines and is handy when you want the full picture of what a given runtime supports.

Keep these handy for the moments a tutorial can’t reach: the exact behavior of an edge case, the full signature of a method, or a straight answer on whether you can ship a feature yet.