Ecma International’s page for ECMA-262 — the standard the world calls JavaScript — lists every published edition in a plain archive table. Between the third and the fifth there is a row with no download link. Its first cell reads:
ECMA-262, 4th edition (not existing)
And its second cell, where every other row offers a PDF, reads:
No file available
That row is the ECMAScript 4 collapse, filed and maintained by the standards body that presided over it. Higher up the same page (loaded 9 September 2026) Ecma explains the mechanism, curly quotes and all:
Please note that for ECMAScript Edition 4 the Ecma standard number “ECMA-262 Edition 4” was reserved but not used in the Ecma publication process. Therefore “ECMA-262 Edition 4” as an Ecma International publication does not exist.
A number reserved and never used. Most standards bodies would quietly skip to five. Ecma kept the row, and it has outlived everyone’s memory of why it is there.
The folk version of why is short and wrong: Microsoft blocked ES4. Both camps wanted a fourth edition. Neither got it — and the whole argument is public, because Ecma’s document server preserves the period’s contributions and minutes. Directory listings return HTTP 403, but individual files resolve at archives.ecma-international.org/{year}/{TG1|TC39}/tc39[-tg1]-{year}-{NNN}.pdf.
The specification supplies the obituary, in the Introduction to the published ECMAScript 2026 edition:
Significant work was done to develop a fourth edition of ECMAScript. However, that work was not completed and not published as the fourth edition of ECMAScript but some of it was incorporated into the development of the sixth edition.
Hold on to that last clause.
Both Papers Asked For a Fourth Edition
Two documents filed a day apart in November 2007 define the disagreement, each side writing its own case rather than having it characterised by the other.
Ecma/TC39-TG1/2007/044 is the ES4 Project Editor’s Report, 8 November 2007, by Lars T Hansen of Adobe Systems. One line in its background materials explains Adobe’s stake:
ES4 baseline document, January 2006 (based on ActionScript 3)
ES4 was not a research language: ActionScript 3 was a shipping implementation of the design, in Flash and Flex, with real users. Hansen describes a project past its open-design phase — “At this time we are no longer accepting new proposals for the language” — on a schedule ending at October 2008: Submission to TC39 for approval.
Ecma/TC39-TG1/2007/042 is six pages authored not by a person but by a company: “Position Statement to TC39-TG1 Regarding the Evolution of ECMAScript”, Microsoft, 7 November 2007. It does not open with a refusal:
Microsoft agrees that it is time to evolve the ECMAScript standard, but we do not see any need or justification for a radical redesign of the language.
Four pages later, under the heading “Refocusing the 4th Edition of ECMAScript”, comes the sentence that should end the folk version for good:
The web needs a 4th Edition of the ECMAScript Specification that codifies conventional usage on the web, corrects known issues, and provides innovative solutions to real web development problems.
The paper proposes four “prioritized tenets” — Stability, Interoperability, Performance, Innovation — in that order, the first being to “Ensure Stability of the existing web platform ecosystem.” The ES4 side was not indifferent to that either. Draft 1 of the proposed specification (Ecma/TC39/2008/040, 16 May 2008) opens its themes with compatibility, before anything else:
Compatibility with ES3 cannot be sacrificed except in situations where compatibility does not make a practical difference, where existing implementations differ or a de facto standard has evolved, or where compatibility would fatally imperil other goals.
Its stated goal was that “ES4 implementations should run all existing ES3 programs”. Hansen reports the same from the editor’s chair: the project was actively “removing facilities that appear to be ill-defined, offer little benefit at high cost, fit poorly with the language, or compromise backward compatibility.”
| ES4 (Adobe, Mozilla, the TG1 majority) | ES3.1 (Microsoft’s position paper) | |
|---|---|---|
| Wants a 4th edition? | Yes — it is the 4th edition | Yes — “The web needs a 4th Edition” |
| Starting point | ActionScript 3, shipping since 2006 | The deployed behaviour of existing browsers |
| Sequence | Design the language, then specify it | Specify what shipped, then extend it |
| Specification method | Standard ML, from a machine-checkable reference implementation | Prose in the existing ES3 formalism |
| Compatibility | First stated theme of Draft 1 | First of four ranked tenets |
| Headline features | Namespaces, packages, classes, optional static types | Codified de facto behaviour, then targeted additions |
Both camps want a fourth edition, agree ES3 is inadequate, and put backward compatibility at the top of their own goal lists. They disagree about sequencing and risk — an ordinary engineering argument, and it deadlocked a standards body for years.
Microsoft’s technical objection is not the aesthetic complaint people remember. “The biggest challenge for any language designer is dealing with the interactions that occur between language features”, it argues, and therefore:
Some of these destabilizing interactions will occur even if a web page or ECMAScript library uses none of the new features of “ECMAScript 4”.
You can be broken by a feature you never used, because “the implementation of each language feature must try to take into account all possible feature interactions whether or not specific features are actually used by a particular program”. Agree or disagree — that is a falsifiable claim about how engines get built, not a matter of taste.
One Edition Number, Two Claimants
So why couldn’t both proceed? The answer is administrative, and Brendan Eich named it in an open letter dated 31 October 2007 — a document that labels itself partisan in its own words: “I’m testifying as an eyewitness”. Read it as one participant’s account, which is what it says it is. This observation, though, is structural rather than partisan:
Readers may not know that Ecma has no provision for “minor releases” of its standards, so any ES3.1 that was approved by TG1 would inevitably be given a whole edition number, presumably becoming the 4th Edition of ECMAScript.
One prize, indivisible. Ecma could not publish a point release, so “ES3.1” could not stay a “3.1” — approving it meant spending edition four on it. Two proposals, one slot, no mechanism for sharing it. A numbering convention produced a technical deadlock, and nothing about the language required that.
The Committee Was Restructured Underneath the Argument
The usual telling ends with a handshake in Oslo. The minutes show something less romantic and more instructive: the machinery was changed while the dispute was still running.
Ecma/TC39/2008/006 records the first meeting of the reconstituted committee, at Google in Mountain View, 24–25 January 2008. The chairman welcomes delegates to “this first historic meeting of the new TC39 (after the Ecma GA decision in December 2007 to split up the old TC39 in two parts).” The task group that had been arguing — TC39-TG1 — was now TC39 itself. Its chair is listed as Brendan Eich, ad interim. Then, under “Selection of the Chairman”:
Microsoft and Adobe jointly announced that they were supporting Mr. Neumann as chairman candidate of TC 39 for the coming year.
By the third meeting in Newton, Massachusetts, 15–18 April 2008, the minutes list the chairman as “Mr. John Neumann (Adobe/Microsoft)” — the affiliation field naming both camps at once. When a body cannot resolve a technical dispute, it changes who convenes the room.
Neumann’s proposed resolution, recorded in the same minutes, was a merger rather than a victory: “the right way to do these two projects is to create ONE specification with conformance classes that are equivalent to ES3.1 and ES4 since 3.1 is equivalent subset of 4.” And alongside it, this condition:
The content of ES4 will have been implemented and tested or it will not be included in the final release.
January 2008 — the essence of what would become Stage 4 of the modern proposal process, written down seven years early, at the meeting that reorganised the committee.
Those minutes also fix the calendar: the year’s meetings were scheduled as March in Mountain View, May in San Francisco, July 23–25 in Oslo, September in Redmond. And ES4 was still moving. Draft 2 (Ecma/TC39/2008/056) is dated 11 July 2008 — twelve days before Oslo, with the October submission target still three months ahead.
Two Accounts of the Same Meeting, Six Days Apart
Two documents describe the decision that came out of Oslo, and they are not the same document.
The participant’s. Brendan Eich, to the es-discuss mailing list, Wed Aug 13 14:26:56 PDT 2008, subject “ECMAScript Harmony”. He writes:
This message is my attempt to announce the main result of the meeting, which I’ve labeled “Harmony”.
His third resolution:
Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.
The institution’s. Ecma/TC39/2008/073, “FOR IMMEDIATE RELEASE”, dated “Geneva, 19 August 2008”, and the white paper filed alongside it. Same decision, six days later, different voice — and four differences worth knowing.
| Eich, es-discuss, 13 Aug 2008 | Ecma, 19 Aug 2008 | |
|---|---|---|
| Who acted | “I worked with John Neumann, TC39 chair, and ES3.1 and ES4 principals” | “John Neumann, TC39 chair, worked with ES3.1 and ES4 principals” |
| Why features died | “deemed unsound for the Web” | “Remove from consideration” |
| Who is credited | Hansen, Miller, Wirfs-Brock | adds Dan Smith (Adobe) |
| What Eich is quoted saying | “3.1 and Harmony … make progress” | “3.1 and beyond … move forward” |
The first row is the sharpest, because both sentences end in the identical phrase “to unify the committee around shared values and a common roadmap.” One sentence, subject swapped: in Eich’s telling he convened the principals; in Ecma’s, the chair convened them and Eich is a name in the list.
The fourth row matters most in practice. Compare exactly:
- es-discuss, 13 August: “Much work remains on 3.1 and Harmony, but we are now on a good footing to make progress as a single committee.”
- Press release, 19 August: Brendan Eich (CTO of Mozilla) said “Much work remains on 3.1 and beyond, but we are now on a good footing to move forward as a single committee”.
Same person, same meeting, six days apart — and only one is what he wrote. Never merge them.
Which brings us to the phrase that has done the most damage. The phrase “deemed unsound for the Web” is quoted everywhere as though it were the committee’s finding. It is not. The string unsound appears zero times in Ecma’s press release and zero times in the accompanying white paper — the two documents recording the decision — and zero times in Microsoft’s position paper. (The check was run after stripping all whitespace from the extracted PDF text, so a spurious intra-word space could not hide a hit; the substring sound also occurs zero times in both Ecma documents.) Ecma’s own wording is flat and administrative:
Remove from consideration the ES4 concepts of “packages,” “namespaces” and “early binding”
Eich was a participant, and a participant’s characterisation of a committee decision is not the committee’s. The white paper is transparently his own text rewritten into institutional voice: it converts “which I sketched with able help from Mark Miller” into “which was sketched by Brendan Eich, with able help from Mark Miller”, then in the very next sentence leaves “I also showed some sugar” standing. The rewrite dropped the justification and kept the first person.
And the outcome was still misnamed. Ecma announced the next standard as “ES3.1 (ECMA-262 Edition 3.1)”. It shipped in December 2009 as the fifth edition.
What package Has Been Waiting For Since 1999
The collapse left two artifacts. The famous one is the row on Ecma’s publications page. The other is in the grammar of every strict-mode program you have ever run.
Open the third edition (December 1999), §7.5.3, “Future Reserved Words”:
The following words are used as keywords in proposed extensions and are therefore reserved to allow for the possibility of future adoption of those extensions.
Thirty-one words follow, and the list — reproduced in full in the table below — is unmistakably Java-shaped.
In December 1999 the standard was already holding a door open for a language with classes, interfaces and packages, which is why Ecma’s 2008 press release could refer, accurately, to “the first ES4 proposals in 1999”. The reservation list is a ledger of intentions, and ES4 was the attempt to cash it in.
Now open the fifth edition — the one that shipped instead of the fourth — at §7.6.1.2. It repeats the 1999 sentence word for word, and cuts the list down:
| ES3 reservation (Dec 1999) | Status in ECMAScript 2026 |
|---|---|
class, const, export, extends, import, super | Cashed in. Real keywords, delivered by the sixth edition in 2015 |
static, let, yield | Cashed in. Real, contextual keywords |
enum | Still unconditionally reserved. Still unused |
implements, interface, package, private, protected, public | Still future reserved words, strict mode only. Still unused |
abstract, boolean, byte, char, double, final, float, goto, int, long, native, short, synchronized, throws, transient, volatile | Released. Dropped by the fifth edition; legal identifiers today |
The published 2026 specification, §12.7.2, note 2, states it plainly:
enum is not currently used as a keyword in this specification. It is a future reserved word, set aside for use as a keyword in future language extensions. Similarly, implements, interface, package, private, protected, and public are future reserved words in strict mode code.
Write let package = 1 in a strict-mode module today and it is a SyntaxError — because in 1999 a committee set the word aside for a feature, in 2008 that feature was removed from consideration for good, and nobody has taken the reservation back since. The fifth edition kept it reserved sixteen months after Ecma removed packages from consideration, using the identical 1999 sentence about “the possibility of future adoption of those extensions”. That is what an unresolved commitment looks like when it fossilises: not a decision to keep it, just the absence of a decision to let it go.
What Actually Survived
Here is ES4 Draft 1, May 2008, listing its “creature comforts”:
ES4 adds proper block scoping and constant bindings, new control structures such as iterators and generators, and getters and setters on objects.
And here is the published 2026 specification summarising what the sixth edition delivered in June 2015:
Some of its major enhancements included modules, class declarations, lexical block scoping, iterators and generators, promises for asynchronous programming, destructuring patterns, and proper tail calls.
Block scoping. Iterators. Generators. Destructuring — which Draft 1 also lists, among its “new syntactic sugar”. Classes. The same list, seven years apart. ES4 did not lose the argument about what JavaScript should eventually have; it lost the argument about how to ship it. What died permanently is the shorter list — namespaces, packages, early binding, optional static typing — the parts that made ES4 a different language rather than a larger one.
A Release Date Nobody Can Hold Hostage
Count the cost in calendar time. Editions one, two and three shipped in thirty months — June 1997, August 1998, December 1999. The fourth never came, and the fifth arrived in December 2009: a ten-year gap, across the decade in which JavaScript became the most deployed runtime on earth.
The committee that emerged from it built a process so the same deadlock cannot form. From the TC39 process document, loaded 9 September 2026:
There are six stages: a strawperson stage and five maturity stages.
Six, not five — 0, 1, 2, 2.7, 3, 4. Stage 2.7 was added by a commit to tc39/process-document dated 1 December 2023 (“add a new testing stage”), so any description of “stages 0 through 4” describes the process as it stood before that. It is a firebreak: a proposal there is “approved in principle and undergoing validation.”
Two clauses do most of the governance work. Stage 4 requires “Two compatible implementations which pass the Test262 acceptance tests” — the committee cannot bless a design into the standard, somebody has to have built it twice, compatibly. And there is no rejection, only retreat: a champion “may request regressing a proposal to an earlier stage, or withdrawing it altogether”, because “The committee does not have an established concept of a rejected proposal–it is always possible for the champion to make changes and come back to ask for consensus.” (The -- is the document’s own punctuation.)
The deepest change is what an edition number now means. Editions one to five were events: the release was a negotiation about scope, so scope was worth fighting over, and a fight could stop the release. Since ECMAScript 2016 was the first ECMAScript edition released under Ecma TC39’s new yearly release cadence and open development process, the release is a cadence — ratification each July, scope being whatever cleared Stage 4 by March. A proposal that is not ready takes the next train, in twelve months. Eleven consecutive June editions have shipped that way, through the seventeenth: ECMAScript 2026, current as of 9 September 2026.
There is a quiet epilogue in the standard itself. Across the whole published 2026 text — 2,102,231 characters after stripping markup, scripts and inline SVG — Harmony, ES4, ECMAScript 4 and Oracle each appear zero times, and JavaScript appears exactly once, crediting an originating technology. The document produced by this fight never names the fight, never names the agreement that ended it, and names the language it defines a single time.
The Position You Are Probably In
Strip out the acronyms and this is a case study in evolving a specification with billions of live dependents and no ability to ship a breaking change. If you maintain a public API, a file format, a wire protocol or a plugin interface other people have built on, you are in a smaller version of the same position.
Fix the date and let scope float. When a release is a negotiation about contents, blocking it is the strongest move available to anyone who dislikes the contents. ES4 died of that; a fixed cadence removes the payoff. And ship in increments you can partially retreat from — ES4 was one monolithic edition, so disagreement about namespaces was disagreement about everything shipping alongside them.
Cheap version numbers de-escalate. Ecma had no minor releases, so the next edition number was a single indivisible prize — a governance decision masquerading as a numbering convention. Make sure your versioning scheme has room for the thing you did not plan.
Distinguish the announcement from the record, even when the same person wrote both. The most-quoted justification for the most-quoted decision in JavaScript’s history appears in neither document the institution published. Before repeating a sentence as an organisation’s position, check whether the organisation ever said it.
The row is still on Ecma’s page, and nobody has tidied it away. A standards body that leaves a numbered gap where an argument used to be is telling you something true about how standards actually get made — which is considerably more useful than a clean list.
❓ Frequently Asked Questions
Was ECMAScript 4 ever published? No. Ecma’s archive lists it as “ECMA-262, 4th edition (not existing)” with “No file available”, and the page explains the number “was reserved but not used in the Ecma publication process.” Two drafts survive in the document archive — 16 May and 11 July 2008 — but no fourth edition was ever ratified.
Did Microsoft block ES4? That flattens the record. Microsoft’s position statement of 7 November 2007 says “The web needs a 4th Edition of the ECMAScript Specification” — it argued about what belonged in it, not whether to have one. Ecma had no way to publish a point release, so approving either proposal spent the number. Neither side got a fourth edition.
Where does “deemed unsound for the Web” come from? Brendan Eich’s message to es-discuss on 13 August 2008 — his own wording as a participant, not a committee finding. The string unsound appears zero times in both Ecma documents describing the same decision; their wording is “Remove from consideration”.
Why was there a ten-year gap between the third and fifth editions? The gap covers the years the committee could not agree what came next. Microsoft’s 2007 paper argues the freeze had an upside — ES3’s stability “was an essential enabler for the recent emergence and broad adoption of Ajax technologies” — and the fifth edition’s main job was writing down what browsers already did.
Why can’t I name a variable package in strict mode? The third edition reserved it in December 1999 as one of thirty-one words “used as keywords in proposed extensions”; ES4 was the attempt to use it; ES4’s packages were removed from consideration in 2008; and the reservation was never withdrawn. Sixteen of those 1999 words — int, boolean, goto and others — were released by the fifth edition and are legal identifiers today. Six were not.
Could a deadlock like this happen again? Not in the same shape. Scope is per-proposal rather than per-edition, a champion can regress or withdraw at any stage, there is no concept of a rejected proposal, and ratification happens each July regardless of what is ready.
Recommended Resources
Some links below are Amazon affiliate links. If you buy through them, this site earns a small commission at no extra cost to you.
Start with the free primary sources — for this subject they genuinely beat the books. Everything quoted in this article came from documents anyone can open:
- Ecma’s document archive — the position papers, minutes, drafts and press release are all public. Directory listings return 403, but individual files resolve at
archives.ecma-international.org/{year}/{TG1|TC39}/tc39[-tg1]-{year}-{NNN}.pdf. Microsoft’s 2007/042 is six pages and worth an evening. - The published ECMAScript 2026 specification — free, and the dated snapshot is the one to cite. The undated
tc39.es/ecma262/is the living draft, which is a different document. - The TC39 process document — a short read that explains more about how the language changes than most books do.
- “JavaScript: The First 20 Years” by Allen Wirfs-Brock and Brendan Eich (ACM, HOPL 2020) — 189 peer-reviewed pages, free to download, co-authored by the language’s designer. Wirfs-Brock appears in this article’s archive documents as Microsoft’s delegate; he later became the editor of the fifth edition.
If you want the period on paper, two of these were written by people who were in the rooms described above:
- JavaScript: The Good Parts — Douglas Crockford. Crockford attended as Yahoo!’s delegate and is listed in the January 2008 TC39 minutes quoted here. The book is the ES3.1 sensibility in argument form: a case that the valuable language was the smaller one already inside the standard.
- Effective JavaScript — David Herman. Herman appears in the April 2008 TC39 minutes and later served on the committee for years. Useful as a picture of what the language actually became once the ES6 features landed.
- You Don’t Know JS: ES6 & Beyond — Kyle Simpson. Not a governance book, but it covers the sixth edition — the release that absorbed block scoping, iterators, generators, destructuring and classes, which is where most of ES4’s surviving ideas ended up.
Book links checked 10 September 2026: all three ASINs pass a check-digit recomputation and match their bibliographic records. Amazon served a bot-check page to the automated request, so current availability and pricing were not confirmed — verify before ordering.