Brendan Eich Built JavaScript in 10 Days. The Prototype Became the Web’s Language.

JavaScript was not designed over years of committee meetings.

Brendan Eich built the first prototype in ten days.

It was May 1995.

Netscape needed a scripting language for its browser.

The Web was exploding.

Java had momentum.

And management wanted something developers could write directly inside web pages.

Eich was given almost no time.

What came out of that rush would eventually run inside virtually every major browser on Earth.

He joined Netscape expecting to work on Scheme

Eich has written that one reason he joined Netscape was the promise of putting a language like Scheme into the browser.

Scheme was elegant and powerful.

But by the time he arrived, the situation had changed.

Sun’s Java was attracting enormous attention.

Netscape was negotiating with Sun.

The browser still needed a lightweight scripting language — something easier and faster to write than Java, but familiar enough that web developers would adopt it.

The political constraint mattered as much as the technical one.

The language could not look too academic.

It needed syntax that felt familiar to programmers coming from C and Java.

At the same time, Eich wanted more flexible ideas underneath.

Then came the ten-day prototype

Eich later wrote very plainly:

“I wrote JavaScript in ten days.”

The engine prototype was built in May 1995.

The language was initially called Mocha.

It was designed to run directly in Netscape Navigator and interpret code embedded in web pages.

Despite the compressed schedule, the prototype already contained ideas that would define JavaScript for decades.

First-class functions.

Prototype-based objects.

Dynamic typing.

Automatic memory management.

A syntax shaped partly by pressure to resemble Java and C.

The name kept changing because the market kept moving

Mocha did not keep its original name.

It became LiveScript.

Then, in late 1995, Netscape and Sun announced JavaScript.

The new name deliberately associated the language with the excitement surrounding Java.

That marketing decision created confusion that still exists today.

JavaScript is not a smaller version of Java.

They have different type systems, object models and design histories.

The names became neighbors before the languages ever did.

The rushed design left technical debt

Eich has never pretended ten days was enough time to design a perfect language.

He has written openly about decisions he would change.

Some awkward parts of JavaScript exist because a prototype became a product before there was time for a clean restart.

Automatic semicolon insertion.

Confusing conversions.

Odd historical behavior around types and objects.

Compatibility constraints then made many of those behaviors difficult to remove.

Once millions of web pages depend on something, even a mistake becomes part of the platform.

But the imperfections helped reveal something bigger

JavaScript succeeded because it made web pages programmable without requiring developers to compile and ship a separate application.

A small piece of code could travel with the page.

The browser already existed on the user’s machine.

The language could react to clicks, change content, validate forms and eventually power entire applications.

The Web stopped being only a collection of documents.

It became a software platform.

That transformation did not happen because JavaScript was theoretically perfect.

It happened because JavaScript was available in the place developers already needed it.

Standardization came after adoption

Success created another problem.

Other browser vendors needed compatible implementations.

Microsoft shipped JScript.

Netscape pushed for standardization through Ecma.

The standardized language became ECMAScript.

From then on, JavaScript had to evolve under a difficult constraint:

Improve the language without breaking the Web.

That is much harder than designing a clean language from scratch.

The “ten days” story is often misunderstood

People repeat it as proof that great products can be built instantly.

That is the wrong lesson.

Eich had years of experience with programming languages and compilers before Netscape.

He was working inside a company with a rapidly growing browser, under unusually strong market pressure, with clear constraints and immediate distribution.

The prototype took ten days.

The knowledge behind the prototype took much longer.

And the language itself has required decades of repair, standardization and evolution.

Speed is powerful when the feedback loop is immediate

The important part of the story is not merely that Eich moved fast.

It is that the prototype could immediately be placed inside a real browser and exposed to real developers.

The feedback loop was short.

Build.

Embed.

Test.

Ship.

Observe.

That environment made a rough prototype unusually valuable.

Many teams today do the opposite.

They spend months polishing architecture before the product reaches a user.

JavaScript’s birth suggests another strategy:

When the market is moving quickly, a good prototype in the right distribution channel can matter more than a perfect design that arrives too late.

But prototypes can become permanent faster than you expect

There is a second lesson, and it is less comfortable.

If a prototype succeeds, people build on it.

Then compatibility becomes a promise.

Then the rough edges become someone else’s dependency.

The thing you thought you would rewrite may become infrastructure.

JavaScript is one of the clearest examples in software history.

A ten-day prototype did not stay a prototype.

It became part of the operating environment of the modern Web.

What are you building as a “temporary prototype” today that might become infrastructure before you ever get the chance to rewrite it?

Explore

Stay connected