Checking a claim without asking anyone

Where the two authoritative documents are, how to read an edition number, and how to ask the runtime in front of you instead of guessing.

JavaScript has a folklore problem worse than most languages. It has been widely written about for thirty years, it changed enormously in 2015, and a great deal of confident advice online was accurate in 2011 and is wrong now. Search results do not carry a date on their face.

The way out is not to know more facts. It is to have a routine for settling any claim in a couple of minutes. Three questions do it.

1. Is this the language, or is it the host? The first lesson's question, and it disposes of a surprising share of confusion by itself.
2. Which edition added it, and is it a finished standard or still a proposal?
3. Does the runtime actually in front of me have it?

Question three is the one you can answer instantly

This is feature detection: asking the runtime whether it has something, rather than working it out from a version number. typeof something === "function" is the standard shape for asking after a method.

It is worth being exact about what typeof protects you from, because the guarantee is narrower than it looks. typeof someName is safe for a bare name that may not exist; that is its one special power, from the lesson on the dead zone. typeof a.b is safe only when a itself exists, because reading a happens first and is an ordinary read with no protection at all.

One step deep is safe, two is not. Intl exists, so reading a property it does not have gives undefined. Reading a property off that undefined is the commonest TypeError in the language, and wrapping the whole thing in typeof does nothing to stop it, because typeof only ever sees the value that reading it produced.

So check one step at a time. The in operator asks whether a name is present without reading its value, and the thing on its right still has to exist.

For a longer chain there is a purpose-built operator. a?.b reads b if a has a value and answers undefined the moment it does not, instead of stopping the program. It is called optional chaining, it arrived in ES2020, and the section on objects covers it properly.

Editions, and what the numbers mean

The specification is revised once a year, and each revision is an edition. The numbering is not tidy, because the naming scheme changed part way through.

ES4 is missing from that table because it was abandoned in 2008 after years of disagreement. That is why the language sat still between 1999 and 2009, and it is worth knowing when you read old writing that talks about a coming version that never arrived.

ES6 and ES2015 are the same document under two names. It was the release that changed the language most, so people still say ES6 to mean modern JavaScript in general, which is now ten years out of date as a phrase.

The two documents worth knowing

MDN Web Docs, at developer.mozilla.org, is the reference you will use daily. It is written for people who are trying to get something done, and every page has two things worth scrolling to: a Browser compatibility table listing which engines support it, and a Specifications link into the standard itself.

Read the compatibility table as "which engines", not "which year". A feature landing in 2021 is available to you or not depending on what your users run, and for a server that is entirely your own decision.

The specification itself is at tc39.es/ecma262, which is the living version updated continuously, with the yearly snapshots published by Ecma International. It is not written to be read from the top, and it is more approachable than its reputation once you know two conventions.

• Everything is written as numbered steps. "Let n be ToNumber(argument)" is an instruction in a procedure, and the procedure is the definition.
• Names such as ToNumber, ToPrimitive and ToString are abstract operations: procedures the specification calls internally. You cannot call them from JavaScript. When the coercion section explains why [] + {} gives a string, it is these that do the work.

Proposals live at github.com/tc39/proposals and move through five stages, 0 to 4. Stage 4 means finished and in the next edition. Stage 3 means engines are implementing it and the design is expected to stand. Anything below that can still change or be dropped, so writing code against it is a bet rather than a decision.

Shrinking a surprise

The last skill is what to do when something behaves in a way you cannot account for. Cut the program down. Remove a line, run it, and see whether the surprise is still there. Keep going until removing one more line makes it disappear.

The semicolon failure from earlier in this section is a good example. It could plausibly have arrived inside a two hundred line file, where the visible symptom is a TypeError about calling something that is not a function. Cut it down and you are left with four lines: two declarations, a sum, and a following line that starts with a bracket.

Those four lines are a claim small enough to search for and small enough to test. That is the difference between being stuck and having a question, and it is worth practising while the programs are small.