Ten Days in May: How JavaScript Was Built Under Deadline
Zusammenfassung
Brendan Eich wrote the first version of JavaScript in ten days in May 1995 under pressure from Netscape management. The language had to exist before a product deadline and had to look superficially like Java (for marketing reasons) while actually being a flexible scripting language for web pages. The design decisions forced by the ten-day timeline — prototype-based inheritance, dynamic typing, first-class functions, the odd coercion rules — became permanent by the time anyone had a chance to reconsider them. Every JavaScript program ever written runs on the consequences of that sprint.
The Pressure
In 1995, Netscape was the dominant web browser company. Netscape 2.0 was in development, and management wanted a scripting language that could run in web pages — allowing web designers to add interactivity without writing Java programs (which required compilation and the full Java SDK). The language needed to be ready before Netscape 2.0 shipped.
Brendan Eich had joined Netscape in April 1995 with the promise of building a Scheme-like language for the browser. By the time he arrived, marketing had made a decision: the language had to have syntax similar to Java. Netscape had just struck a deal with Sun Microsystems to bundle Java in the browser; a scripting language that looked like Java would strengthen the association. Eich had no input into this decision.
He spent approximately 10 days in May 1995 creating the language — originally called “Mocha,” then “LiveScript,” then “JavaScript” in December 1995 when the name change was made for marketing reasons.
The Design Decisions
The ten-day timeline produced a language with unusual properties:
Prototype-based inheritance: Java used class-based inheritance; Eich wanted Scheme-like closures; the compromise was prototype chains — objects inherit directly from other objects, no class declaration required. This was flexible and unusual in a mainstream language in 1995.
Dynamic typing with coercion: Variables have no declared types; the language tries to convert values to compatible types before operations. This produces the infamous behaviors: "5" + 3 = "53" but "5" - 3 = 2. The coercion rules were designed for convenience and produced surprises.
First-class functions: Functions are values; they can be assigned to variables, passed as arguments, returned from other functions. This came from Scheme. It was unusual in a mainstream language and turned out to be the most powerful feature.
null and undefined both exist: Two distinct empty values — null (intentionally empty) and undefined (never assigned). The distinction causes confusion in every JavaScript program. It was never designed; it accumulated.
The Permanence of the Mistakes
When Netscape 2.0 shipped with JavaScript in March 1996, millions of web pages began using it immediately. By the time anyone surveyed the design and noticed the coercion surprises and the null/undefined redundancy, fixing them would have broken every existing page. The language was frozen into permanence by deployment.
The same pattern — “we’ll fix it later” followed by “we can’t fix it because of deployment” — repeated with every subsequent version of JavaScript. ES6 (2015) added classes (syntactic sugar over prototypes), let and const (to supplement var), arrow functions, and many other improvements. But the original coercion rules are still there. The typeof null === "object" behavior (a bug from the original ten days) is still there. Removing it would break too many programs.
Brendan Eich has described the experience of those ten days with characteristic directness: the language he built was the right thing for the moment, built under the wrong conditions, and then frozen by success before it could be improved.