The standard answers the question itself. Anyone asking who invented JavaScript can read it in the Introduction to ECMAScript 2026, the published edition, in one sentence:
The language was invented by Brendan Eich at Netscape and first appeared in that company’s Navigator 2.0 browser.
That is the only time Brendan Eich’s name appears anywhere in the specification. Loaded and string-matched on 2026-09-09, the 7,521,350-byte document contains Eich once, Netscape twice, JavaScript once, and Mocha and LiveWire zero times each. One sentence of credit, and then 2.1 million characters of consequences.
The popular version adds a number to that sentence — ten days — and then usually spends a paragraph implying the number is an exaggeration, a legend, or a joke at the language’s expense. It is none of those. It is Eich’s own claim, in his own words, on his own site, repeated for two decades. The useful work is not correcting it. The useful work is reading the rest of the sentence he wrote immediately after it, because that sentence says something almost nobody repeats: what got built in those ten days was a bytecode compiler, and part of the reason was a server.
“Engine prototype took ten days in May”
Eich’s post of 21 June 2011, New JavaScript Engine Module Owner, opens flatly: “As you may know, I wrote JavaScript in ten days.” Further down the same post, in a paragraph of clipped notes he says himself is written in fragments — “show my PTSD from that sprint” — he gives the technical accounting:
That was 1995. Engine prototype took ten days in May. Bytecode compiler and interpreter from the start, because Netscape had a server-side JS product in the works. The rest of the year was browser integration, mainly what became known as “DOM level 0”.
Read that as a project plan rather than an anecdote and the whole shape changes. The ten days produced an engine prototype. The rest of 1995 — roughly eight further months — was integration work: wiring the language into a browser and inventing, along the way, the object model that would later be back-named DOM level 0. The ten days are the opening move, not the whole game. Eich says so in the same breath as the claim everyone quotes.
The peer-reviewed history agrees and adds the missing precision. JavaScript: The First 20 Years — 189 pages by Allen Wirfs-Brock and Brendan Eich, in Proc. ACM Program. Lang. Vol. 4, HOPL, Article 77, June 2020 — puts the sprint “in ten contiguous days in May, 1995” and is candid in a footnote about the limits of the record — “There is no known record of the specific dates” — and goes on to give Eich’s own belief that the window was 6–15 May. That hedge, from the person who wrote the code, is the most honest form of the claim available, and it is stronger than the folklore, not weaker.
The paper is also blunt about what the sprint was for: “This work was rushed to meet a feasibility demonstration deadline.” Netscape had already decided it wanted a second, smaller language alongside Java. What it had not established was that it could build one before the Navigator 2.0 beta in September. The ten days were the proof.
A Lexer, a Parser, a Bytecode Compiler, and a Decompiler
Here is the part that gets lost when “ten days” is treated as a punchline. The HOPL paper describes the prototype’s internals directly: “The prototype used a hand-written lexer and recursive-descent parser. The parser emitted bytecoded instructions rather than a parse tree.” A footnote records that it used a large discriminated union to represent values, and reference counting for memory management.
Emitting bytecode rather than walking a tree is not the shortcut. It is the longer road. A tree-walking interpreter is the thing you build when you are in a hurry; a compiler that lowers to a bytecode and an interpreter that executes it is the architecture you choose when someone downstream needs load-and-go performance. Someone did, and that is the next section.
There was a fourth component, and its cause is the most 1995 thing in the entire story. The prototype supported eval, on the theory, per the paper, that “The intuition was that this kind of dynamic string-to-program programming would be important for some applications on Web browsers and servers.” Supporting eval meant functions had to be able to hand back their own source text through a Java-style toString. So, in the paper’s words, “Eich chose to implement a bytecode decompiler in his ten-day sprint” — because keeping the original source around, or paging it back in, was judged too expensive: “source code primary storage or recovery from secondary storage seemed too costly for some required target architectures.” The architecture in question was the 16-bit segmented memory model of Windows 3.1.
A machine that has been commercially irrelevant for thirty years is why JavaScript functions have always been able to print themselves. That is a more interesting fact than it was rushed.
The Server Was Already in the Room
The name of the downstream consumer was LiveWire, Netscape’s server-side scripting product. HOPL states the dependency in one line — “Bytecode was a requirement of Netscape’s LiveWire server” — and then explains who wanted it and why: “The team’s ex-Borland management and engineering staff were big believers in dynamic scripting languages but wanted bytecodes, rather than source parsing, for faster server application loading.”
Faster server application loading. In May 1995.
It is not one influence, either. Three separate design decisions in the record trace to the same server team:
- Bytecode, above, as a hard requirement before the language had been prototyped at all.
- The dynamic object model. Properties can be added to an object after it exists, with no declaration and no schema. HOPL: “This very dynamic approach was especially favored by the LiveWire team.”
with. The statement most often filed under 1995 mistakes was not in the sprint. HOPL’s footnote 15: “Thewithstatement was added after the ten-day Mocha sprint at the request of the Netscape LiveWire team.” It is a post-sprint accommodation to a second product, and it is still in the language today — §14.11 of ES2026 carries it with a Legacy tag and a note that its use “is discouraged in new ECMAScript code.”
There is a footnote on page 77:8 that reframes the whole origin story in a single line, and it is the one fact from this research that nobody writes: “Brendan Eich had spent his first month at Netscape officially working in the server group.”
The launch announcement says the same thing out loud. The Netscape and Sun press release of 4 December 1995, recovered from the Wayback Machine’s 8 October 1997 capture of www28.netscape.com, describes the new language as “an easy-to-use object scripting language designed for creating live online applications that link together objects and resources on both clients and servers”, and states the audience directly: “JavaScript is designed for use by HTML page authors and enterprise application developers to dynamically script the behavior of objects running on either the client or the server.”
Count the words in that release and the framing gets sharper. Isolating the body of the announcement between its Mountain View dateline and the boilerplate, and stripping <script>, <style> and <svg> before removing tags, client appears 9 times and server appears 9 times. browser appears twice, and neither instance is about JavaScript — one is HotJava, one is Java-enabled browsers used as front-ends. The document that announced JavaScript to the world mentions the browser less often than it mentions the database.
One of its worked examples reads like a Node.js tutorial written thirteen years early: “A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly.”
And it shipped. HOPL records that Netscape Enterprise Server 2.0 “incorporated JavaScript 1.0 within its LiveWire server-side scripting component”, in March 1996 — the same month Navigator 2.0 shipped with JavaScript 1.0 in the browser. Server-side JavaScript is not a 2009 idea that Node.js invented. It is a 1996 product that shipped simultaneously with the browser version, from the same company, using the same engine.
Why it did not stick is a genuinely open question, and this article does not answer it. No source loaded for this piece addresses LiveWire’s decline directly, and the honest position is to name the gap rather than fill it with a plausible story. What can be said with a citation is narrower and still worth having: the server was not an afterthought bolted onto a browser language. It was a requirement that shaped the implementation before the language had a public name.
Four Names, and Not One of Them Chosen for a Technical Reason
The naming story is usually told in one step: it was called Mocha, then they renamed it JavaScript to ride Java’s marketing wave. Both halves of that are wrong — the chain has four links, and the wave-riding was the plan before the first line of code, not a reaction after it.
| Name | Live when | What ended it |
|---|---|---|
| Mocha | May–mid 1995, internal codename | Netscape marketing disliked it; the rename to JavaScript was expected from the start |
| LiveScript | Sept 1995 public beta through at least 13 Nov 1995 | The Sun trademark licence closed on 4 Dec 1995 |
| JavaScript | 4 Dec 1995 onward | Nothing — but Sun owned the trademark, and would not license it to a standards body |
| ECMAScript | Sept 1997 onward, for the standard only | Nothing. It was the placeholder, and it stuck |
Start with the codename. HOPL, page 77:8: “Marc Andreessen proposed the code-name “Mocha” for the browser scripting language with, according to Eich, the hope that the language would be renamed “JavaScript” in due course.” The destination was chosen with the codename. There was no reaction to scramble from, because the rename was not a reaction — it was the plan, waiting on a partnership deal to close.
This matters because the opposite claim is one of the most-cited lines in JavaScript folklore, and its actual provenance is worth knowing. The sentence “renaming LiveScript to JavaScript was scrambling in reaction to Java” does appear on brendaneich.com — in a reader’s comment on Eich’s 3 April 2008 post Popularity, posted by John Stracke and timestamped 2008-04-04T06:46:50+00:00 in the page’s own markup. And Stracke is not asserting it. He is retracting it: “I thought that renaming LiveScript to JavaScript was scrambling in reaction to Java; I didn’t realize you’d been expecting to support both of them even before 2.0 was released.” A reader saying the post I just read corrected me has been quoted for years as though it were the post.
LiveScript, meanwhile, was not a footnote. It was the real, shipping, public name. A contemporaneous trade report — TidBITS, 13 November 1995, three weeks before the rename — describes the second Navigator 2.0 beta as offering “preliminary support for LiveScript, Netscape’s own scripting language”, and adds, with the scepticism of the moment:
LiveScript is by Netscape’s own admission “lightweight,” which means there are significant limitations to what people can do with it.
It also notes that LiveScript “is not part of any standard specification and (naturally) is only supported in Netscape’s browsers”. Both observations were accurate, and both stopped being true.
As for why a scripting language was made to look like Java at all: that mandate is documented, and it was not Eich’s. From Popularity: “The diktat from upper engineering management was that the language must “look like Java”. That ruled out Perl, Python, and Tcl, along with Scheme.” HOPL states the same decision from the committee side: “Rapid strategizing inside Netscape to choose a scripting language severely handicapped Scheme, Perl, Python, Tcl, and Visual Basic as not viable due to business interests and/or time to market considerations.” Eich had been recruited to do something else entirely: “I was recruited to Netscape with the promise of “doing Scheme” in the browser.” He says plainly that “Scheme was the bait I went for in joining Netscape.”
The business case for two languages was argued by analogy, not by engineering. HOPL: “Java in spring 1995 was not a suitable language for beginners.” Microsoft’s own product line supplied the template — Visual C++ for professionals, Visual Basic for everyone else. Eich records Bill Joy reaching the same framing independently at Sun: “Bill grokked the idea of an easy-to-use “scripting language” as a companion to Java,” and adds, “He was, as far as I can tell, our champion at Sun.” Six months later that analogy was in the joint press release verbatim as approved corporate copy: “JavaScript is analogous to Visual Basic in that it can be used by people with little or no programming experience to quickly construct complex applications.”
ECMAScript Is the Name Nobody Chose
The chain does not end at JavaScript, and the fourth link is the one most accounts skip entirely.
When TC39 began standardising the language in late 1996, it could not use either name already in circulation. Sun owned the “JavaScript” trademark and had licensed it to Netscape; per HOPL, Sun confirmed it would not license the name to Ecma. TC39 then tried LiveScript. Netscape raised no legal objection but never transferred the name: “This precluded the use of LiveScript as the name of the language as Netscape had decided that it was not willing to formally transfer the name to Ecma.” A footnote adds Eich’s own read of that offer — “Brendan Eich believes that Netscape was never serious about allowing Ecma to use the name LiveScript.”
There was also a principled objection that had nothing to do with either company. At the Ecma General Assembly, per HOPL, “there were concerns about the appropriateness of using a trademarked name in the title of a standard as the intent of a standard is to place all companies implementing the standard on equal footing.” Whichever brand won, the standard would have carried one vendor’s asset in its title.
So the committee ran a search. Scott Wiltamuth “presented a list of sixteen potentially viable names and fourteen names that were thought to be nonviable because of existing trademarks or conflicting usages. A straw poll identified the top candidate names: LiveScript, ScriptJ, EZScript, Xpresso/Expresso/Espresso.” None of them resolved anything. “ECMAScript” had been adopted at the first TC39 meeting as a placeholder to use in drafts until a real name was found, and the General Assembly eventually approved the standard under the placeholder. Eich’s verdict, quoted in the paper he co-authored: “ECMAScript was always an unwanted trade name that sounds like a skin disease.”
Four names, three renames, and not one of them decided on technical grounds. The market chose the first, a partnership deal chose the second and third, and trademark law chose the fourth by elimination.
The August Freeze Decided More Than the May Sprint
If you want to know which of JavaScript’s oddities the ten days are actually responsible for, the answer is: fewer than you would think, and a different set than the usual list.
The sprint was not the binding deadline. HOPL is explicit that JavaScript’s development “was constrained by the overall Navigator 2.0 schedule that required a feature freeze in August 1995. The JavaScript 1.0 feature set was essentially a triage of what was working or near working in the Mocha implementation that August.” Four months after the sprint, a browser release schedule — not the language design, and not the ten days — decided what shipped.
What the freeze left out is startling to a modern reader. The paper’s Figure 3 lists features in common use by around 2010 that JavaScript 1.0 simply did not have: a distinct Array object type, array and object literals, regular expressions, a global binding for undefined, the === operator, typeof, void and delete, in and instanceof, do-while, switch, try–catch–finally, labelled break and continue, nested function declarations, function expressions, call and apply, the prototype property of functions, access to built-in prototype objects, cyclic garbage collection, and the src attribute on <script> tags.
Here is where the surviving oddities actually come from:
| Artefact still in the language | Where it came from | Not from |
|---|---|---|
typeof null === "object" | The ten-day value-tagging scheme — null shared an internal tag with objects, so typeof needed no special case | A design decision about what null is |
with | Added after the sprint, at the LiveWire team’s request | Ten-day haste |
Y2K-era Date bugs | Ported from JDK 1.0-era java.util.Date under the look-like-Java mandate | Anything Eich designed |
string versus String | The same mandate — Java’s primitive/object split, copied to the surface | Prototype-based semantics |
Function decompilation via toString | The eval decision, plus Windows 3.1’s segmented memory | A language-design goal |
The Date lineage has a name attached. From the 2011 post: “Ken Smith, a Netscape acquiree from Borland, ported JDK 1.0-era java.util.Date”, and Eich adds the reasoning without softening it — “we both just drafted off of the Java truck, per management orders; we did not demur from the Y2K bugs in that Java class”. In 2008 he had already logged the cost: “I’m not proud, but I’m happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients. The Java influences, especially y2k Date bugs but also the primitive vs. object distinction (e.g., string vs. String), were unfortunate.”
typeof null is the famous one, and it is worth being precise about what the ten days are responsible for. They produced the tag collision. They did not produce its permanence — that came from two separate later refusals to fix it, each on a stated design principle, which a companion piece in this series takes apart properly. The sprint made the wart. Thirty years of committee decisions kept it.
Eich Rewrote It Himself, Eighteen Months Later
One last thing the ten-day framing obscures: the ten-day code did not survive.
By late 1996 Eich was still the only engineer on the language, maintaining it across shipping and future Netscape releases along with the DOM code, while under pressure to write a proto-specification. His account, from the same 2011 post:
So I actually stayed home for two weeks to rewrite Mocha as the codebase that became known as SpiderMonkey, mainly to get it done (no other way), also to go on a bit of a strike against the Netscape management team that was still underinvesting in JS.
The rewrite was substantive, not cosmetic: “This entailed garbage collection and tagged values instead of slower reference-counting and fat discriminated union values.” HOPL’s own timeline places the work in Q3 1996; Eich describes it as fall.
Two things follow. First, SpiderMonkey — still shipping in Firefox today — is a rewrite, not the 1995 tree carried forward. The lineage is real in authorship and intent, and false if taken literally. Second, the second sprint has the same shape as the first: one engineer, compressed, solo, forced by circumstance. The difference is the forcing function. The first sprint was pressure from a partnership deal. The second was, in his own characterisation, leverage against his own management.
That is the honest answer to who invented JavaScript. One person, twice, alone, under two different kinds of deadline, for a company that wanted a marketing companion to somebody else’s language and got a general-purpose runtime instead. The standard’s Introduction says so in twenty words and then, two sentences later, records where it ended up: “Though best known as the language embedded in web browsers, it has also been widely adopted for use outside the browser, including server and embedded applications”.
Which, as the December 1995 press release shows, is exactly where it started.
❓ Frequently Asked Questions
Did Brendan Eich really write JavaScript in ten days? Yes, and the claim is his own — he has published and repeated it since at least 2011. What the ten days produced was the Mocha prototype: a lexer, a recursive-descent parser, a bytecode compiler, a bytecode interpreter and a decompiler, demonstrated to Netscape’s engineering staff at the end of the window. HOPL puts the sprint in May 1995 and notes there is no surviving record of the exact dates, giving Eich’s recollection of 6–15 May. Eich’s own summary of the rest of that year: “The rest of the year was browser integration”.
Why is it called JavaScript if it has nothing to do with Java? Because Netscape licensed the trademark from Sun as part of a partnership deal announced on 4 December 1995, and because Marc Andreessen picked the codename “Mocha” already expecting the rename. The two companies had a coherent commercial story — the press release calls JavaScript “analogous to Visual Basic in that it can be used by people with little or no programming experience” — with Java in the Visual C++ role. The syntactic resemblance was a management mandate, not a technical inheritance.
Was JavaScript originally a browser-only language? No. Netscape’s LiveWire server product was a stated requirement before the prototype existed, and it is why the prototype emitted bytecode instead of walking a parse tree. Netscape Enterprise Server 2.0 shipped with JavaScript 1.0 in its LiveWire component in March 1996, the same month Navigator 2.0 shipped. Why that attempt did not become durable infrastructure while Node.js later did is a real open question, and not one this article can source an answer to.
What is the difference between JavaScript and ECMAScript, historically? “ECMAScript” was adopted at the first TC39 meeting as a placeholder because the committee could use neither existing name: Sun would not license “JavaScript” to Ecma, and Netscape declined to transfer “LiveScript”. Ecma’s General Assembly also objected in principle to putting a trademarked name in a standard’s title, on the grounds that a standard should place all implementers on equal footing. Sixteen candidate names were screened and a straw poll went nowhere; the placeholder was approved and never replaced.
Which JavaScript quirks are actually the ten days’ fault? typeof null === "object" is, in the sense that the ten-day implementation gave null and objects the same internal type tag. Function toString decompilation is, indirectly, via eval and Windows 3.1’s memory model. The with statement is not — HOPL records it as added after the sprint for the LiveWire team. The Y2K Date bugs and the string/String split are not either; both came from copying Java under the look-like-Java order.
Is SpiderMonkey the original 1995 code? No. Eich rewrote Mocha over two weeks in late 1996, replacing reference counting and discriminated-union values with garbage collection and tagged values, and that rewrite is what became SpiderMonkey. HOPL’s timeline places it in Q3 1996. The original ten-day engine did not survive its second year.
📦 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.
On this particular subject the free primary documents beat every book, so start there. JavaScript: The First 20 Years by Allen Wirfs-Brock and Brendan Eich is 189 peer-reviewed pages, free to download, co-authored by the person who wrote the prototype — pages 77:7 to 77:12 cover the ten days, LiveWire’s requirements and the August 1995 feature freeze; section 10, at 77:38 to 77:39, is the naming fight in full. Eich’s own posts of 3 April 2008 and 21 June 2011 are the first-person source for the sprint and the SpiderMonkey rewrite, and the reader comments underneath the 2008 post are worth reading precisely because one of them is the origin of a myth. The Netscape and Sun press release of 4 December 1995 survives in the Wayback Machine, and Ecma’s document archive still hosts the preliminary JavaScript 1.1 specification Eich submitted to TC39 in November 1996. The books below are for the layer around all that.
- Coders at Work: Reflections on the Craft of Programming by Peter Seibel (Apress, 2009) — the HOPL paper itself points readers here, citing chapter 4 for a more detailed look at Eich’s early career. Seibel interviews fifteen programmers at length about how they actually work, and the value for this subject is calibration: read enough of these and the ten-day sprint stops looking like a freak event and starts looking like what a competent implementer does when handed an impossible deadline and left alone.
- Structure and Interpretation of Computer Programs by Harold Abelson, Gerald Jay Sussman and Julie Sussman (MIT Press, 2nd edition, 1996) — the book behind the language JavaScript was supposed to be. Eich was recruited to Netscape on the promise of “doing Scheme” in the browser, and while the diktat killed the syntax, the first-class functions survived and are now the most-used idea in the language. Working through SICP is the fastest way to see which parts of modern JavaScript are Scheme wearing a C-family costume, and which parts are the costume.
- How the Internet Happened: From Netscape to the iPhone by Brian McCullough (Liveright, 2018) — the commercial context the language was built inside. The Sun partnership, the Java licensing deal, the Navigator release schedule and the browser-war economics are not background colour here; they are the direct causes of a bytecode compiler, a trademark, and a feature freeze in August. This is the readable account of why a browser company was making product decisions at that speed in 1995.
✅ Pro tip: When you meet a claim about a language’s origins, check whether the sentence is in the post or in the comments underneath it. The most-repeated line about the JavaScript rename lives in a reader’s comment on Eich’s blog — and that reader was describing a belief the post had just corrected. Blog platforms render both in the same typeface, and quote-collectors rarely note the difference.