119 The History of JavaScript — From a Ten-Day Experiment to the Language of the Web

The Technologies That Built the Web

HTML gave the web documents.

CSS would give those documents presentation and design.

PHP and databases would eventually make websites dynamic on the server.

But something important was still missing.

What if a web page itself could react to the person using it?

What if clicking something could change the page without requesting an entirely new document?

What if a form could be checked before it was submitted?

What if menus could open, images could change, calculations could happen, and eventually entire applications could operate inside the browser?

For that, the web needed a programming language of its own.

That language became JavaScript.

The Early Web Was Mostly Documents

The original World Wide Web was designed primarily around documents and links.

A browser requested an HTML document from a web server.

The browser displayed it.

The user clicked a link.

The browser requested another document.

It was a wonderfully simple model.

But as the web grew during the early 1990s, developers began imagining something more interactive.

Could the browser do more than display documents?

Netscape and the Browser Revolution

One of the most important companies in the early commercial web was Netscape Communications.

Netscape Navigator became an enormously popular web browser during the mid-1990s.

Netscape wanted websites to become more interactive.

The company needed a programming language that could run directly inside the browser.

The idea was not necessarily to create another large, complicated programming environment.

The language needed to be approachable enough that web designers and developers could add behavior to their pages.

Brendan Eich

In 1995, Netscape hired programmer Brendan Eich.

Eich was given the task of creating a scripting language for the browser.

And he was given very little time.

The first version of the language that became JavaScript was created in approximately ten days.

Few technologies demonstrate the unpredictability of computing history better than this.

A language created under extraordinary time pressure would eventually become one of the world's most widely used programming languages.

Ten Days Does Not Mean the Language Stopped Evolving

The famous “ten days” story can be misleading if taken too literally.

Eich did not create every feature of modern JavaScript in ten days.

He created the first implementation and fundamental design of the language during that remarkably short period.

JavaScript then spent decades evolving.

Features were added.

Mistakes were addressed where possible.

Standards were developed.

Browser engines became dramatically faster.

The language grew far beyond its original purpose.

First It Was Mocha

The language did not initially have the name JavaScript.

During development it was known as Mocha.

It was then called LiveScript.

Finally, in late 1995, it became JavaScript.

That last name would create confusion for decades.

Java and JavaScript Are Not the Same Thing

Java was also receiving enormous attention in the mid-1990s.

Created at Sun Microsystems, Java was being promoted as a language capable of running software across different computer platforms.

Netscape and Sun were working together commercially, and the name JavaScript helped associate Netscape's new scripting language with the excitement surrounding Java.

But despite the similar names:

Java and JavaScript are different programming languages.

They have different histories, designs, and uses.

The naming relationship was largely a product of the technology environment and marketing of the 1990s.

JavaScript Reaches the Browser

JavaScript appeared in Netscape Navigator 2.0.

For the first time, web developers had a widely distributed programming language that could execute directly inside the visitor's browser.

This was fundamentally different from server-side programming.

PHP executes on the server.

The server sends the result to the browser.

JavaScript can execute inside the browser after the page arrives.

That distinction remains extremely important today.

Server-Side Versus Client-Side

Consider a PHP page.

The request might travel like this:

Browser → Apache/nginx → PHP → MySQL → PHP → Web Server → Browser

PHP executes on the server.

The browser normally receives the resulting HTML, not the PHP source code.

JavaScript traditionally operates differently:

Server → JavaScript → Browser → JavaScript Executes

The browser receives the JavaScript and runs it locally.

JavaScript therefore became known primarily as a client-side programming language.

The Browser Became a Computing Environment

This was a major conceptual change.

A web browser was no longer merely a document viewer.

It could execute programs.

Those programs could react to user actions.

A mouse click could trigger code.

A keyboard action could trigger code.

Submitting a form could trigger code.

Loading a page could trigger code.

The browser became an application platform.

Events

One of JavaScript's fundamental concepts is the event.

Something happens.

JavaScript responds.

The user clicks a button.

The mouse moves over an element.

A field changes.

A page finishes loading.

A key is pressed.

A timer expires.

JavaScript can listen for those events and perform an action.

This event-driven model became one of the foundations of interactive web development.

Microsoft Enters the Browser War

Netscape's success did not go unnoticed.

Microsoft began aggressively developing Internet Explorer.

Microsoft created its own implementation of the language, called JScript.

Now an important problem emerged.

If browsers implemented scripting differently, developers could not depend upon the same code working everywhere.

The web needed standards.

ECMAScript

Netscape submitted JavaScript for standardization to Ecma International.

The standardized language became known as ECMAScript.

The first ECMAScript standard was published in 1997.

This gives us another terminology distinction:

ECMAScript is the standardized language specification.

JavaScript is the most familiar implementation and name used by developers.

In ordinary web development, people usually simply say JavaScript.

The Browser Wars

During the late 1990s, Netscape Navigator and Microsoft Internet Explorer competed intensely.

Both companies wanted their browsers to offer capabilities the other did not.

That competition accelerated innovation.

It also created headaches.

Web developers sometimes had to write different code for different browsers.

A feature might work in Internet Explorer but not Netscape.

Another might work in Netscape but behave differently elsewhere.

Anyone developing websites during this period learned an important lesson:

“Works in my browser” does not necessarily mean “works on the web.”

Dynamic HTML

During the late 1990s, the term DHTML, or Dynamic HTML, became popular.

DHTML was not really a separate programming language.

It described the combination of technologies that could make pages change after loading.

Typically that meant some combination of:

• HTML
• CSS
• JavaScript
• The browser's Document Object Model

JavaScript could manipulate elements of the page, changing their content, position, visibility, or appearance.

The webpage was becoming something that could change while you were looking at it.

The Document Object Model

To modify a webpage, JavaScript needs a way to understand its structure.

That structure is represented through the Document Object Model, usually called the DOM.

The browser interprets the HTML document and creates an internal representation of the page.

JavaScript can interact with that representation.

It can locate an element.

It can change text.

It can add or remove elements.

It can change classes and styles.

It can react when the user interacts with those elements.

This relationship between HTML, the DOM, and JavaScript remains central to web development.

HTML, CSS, and JavaScript

The modern front-end web eventually developed a useful division of responsibilities.

HTML provides structure and meaning.

CSS controls presentation and layout.

JavaScript provides behavior and interactivity.

The boundaries are not always perfect, but this is an excellent mental model.

These three technologies became the core languages understood directly by the browser.

JavaScript Gets a Bad Reputation

JavaScript's early years were not always elegant.

Developers used it for useful form validation and navigation.

They also used it for blinking text, pop-up windows, status-bar messages, animations, intrusive advertising, and effects that visitors sometimes wished had never been invented.

Browser incompatibilities made matters worse.

JavaScript gained a reputation in some circles as an annoying or unreliable scripting language.

But underneath the questionable experiments was something extremely powerful:

the ability to program the browser.

Pop-Ups and the Battle for Control

JavaScript demonstrated another challenge that would follow web development for decades.

Who controls the browsing experience?

The website?

The browser?

Or the user?

JavaScript could open windows and manipulate aspects of the interface, and advertisers quickly exploited those capabilities.

Browsers eventually added restrictions and pop-up blocking.

The pattern would repeat many times:

A powerful new browser capability appears.

Developers find useful applications.

Someone abuses it.

Browsers add protections.

The Quiet Years

After the browser wars, Internet Explorer became overwhelmingly dominant for a period.

JavaScript continued to be used, but development of the language standard slowed.

There were disagreements over how ambitious future versions should become.

For a time, JavaScript seemed less revolutionary than it had during its introduction.

Then something happened that dramatically changed its future.

XMLHttpRequest

Microsoft had introduced a browser capability that allowed scripts to communicate with servers without requiring the entire page to reload.

This capability eventually became available through an object known as XMLHttpRequest.

At first, its larger significance was not obvious.

But developers began realizing that JavaScript could quietly request additional information from the server while the user remained on the same page.

That changed everything.

AJAX

In 2005, the term AJAX became popular.

It stood for Asynchronous JavaScript and XML.

The important idea was not really XML.

The important idea was asynchronous communication.

JavaScript could send a request to the server in the background.

The server could return information.

JavaScript could update part of the existing page.

No full-page reload was required.

The Page Could Talk to the Server

Before this approach became common, interacting with a web application often meant:

Click → Request New Page → Server Generates Page → Browser Reloads

AJAX made another pattern practical:

JavaScript → Server Request → Data Returned → JavaScript Updates Page

The browser and server could maintain an ongoing conversation.

Websites began behaving much more like desktop applications.

Google Maps Changes Expectations

Applications such as Google Maps helped demonstrate what this new style of web programming could accomplish.

A user could drag a map and see new areas appear without reloading the entire webpage.

That experience seems ordinary today.

At the time, it was remarkable.

The web page was becoming an application.

JavaScript Comes Back to Life

AJAX triggered enormous renewed interest in JavaScript.

Developers wanted better ways to manipulate pages, handle browser differences, create effects, and communicate with servers.

Libraries began appearing to simplify the work.

One would become particularly influential.

jQuery

John Resig introduced jQuery in 2006.

Its goal was to make common JavaScript operations easier and more consistent across browsers.

Tasks that previously required complicated browser-specific code could often be performed with much simpler jQuery commands.

Its famous philosophy was:

“Write less, do more.”

For many years, jQuery became nearly synonymous with practical JavaScript development.

Why jQuery Was So Important

Modern browsers have standardized many features that once required libraries.

That can make it difficult to appreciate how valuable jQuery once was.

Browser inconsistencies were a serious development problem.

jQuery provided a compatibility layer.

A developer could write code using jQuery and allow the library to deal with many differences underneath.

It made JavaScript much more approachable during a crucial period of web development.

The Browser Engines Get Faster

As web applications became more sophisticated, browser makers began competing heavily on JavaScript performance.

JavaScript engines became dramatically faster.

Mozilla developed increasingly capable JavaScript technology for Firefox.

Apple developed JavaScriptCore for Safari.

Google introduced its V8 JavaScript engine with Chrome in 2008.

V8 was designed for high-performance JavaScript execution.

This would have consequences far beyond the browser.

JavaScript Escapes the Browser

For most of its early life, JavaScript meant one thing:

code running in a web browser.

Then, in 2009, Ryan Dahl introduced Node.js.

Node.js used Google's V8 engine to run JavaScript outside the browser.

Suddenly JavaScript could be used to write server software.

The language that had been created to add simple behavior to Netscape pages could now operate on the other side of the internet connection.

Client-Side and Server-Side JavaScript

This produced an interesting situation.

JavaScript could run in the browser:

Browser → JavaScript

And JavaScript could run on the server:

Browser → Node.js → Database or Other Services

A development team could potentially use JavaScript on both sides.

That helped make JavaScript even more important.

JavaScript Was No Longer a Little Scripting Language

By this point, JavaScript had moved far beyond form validation and rollover images.

Developers were using it to create:

• Complex web applications
• Server applications
• Real-time communication systems
• Development tools
• Desktop applications
• Mobile applications
• Command-line programs
• Games
• Browser extensions

The ten-day browser scripting project had become a general-purpose programming platform.

ECMAScript Evolves

The language standard continued evolving as JavaScript's importance grew.

ECMAScript 5 arrived in 2009 and helped modernize and standardize the language.

An even larger change arrived with ECMAScript 2015, commonly called ES6.

ES6 introduced many features that helped make JavaScript more suitable for large modern applications.

These included classes, modules, arrow functions, improved variable declarations, promises, template literals, and numerous other language improvements.

JavaScript was maturing.

Frameworks Arrive

As web applications grew larger, developers needed better ways to organize increasingly complex JavaScript code.

Libraries and frameworks emerged.

Angular became influential.

React changed how many developers thought about user interfaces.

Vue offered another approach.

Many others appeared.

The front-end web increasingly began resembling traditional software engineering.

The Single-Page Application

One major architectural idea was the Single-Page Application, or SPA.

Instead of loading a completely new HTML document for every interaction, an application could load a substantial JavaScript environment and then dynamically update the page as the user moved through the application.

The browser could request data from APIs and construct much of the experience locally.

This made extremely sophisticated browser applications possible.

It also introduced new complexity.

Sometimes We Used Too Much JavaScript

As JavaScript became more powerful, developers sometimes used it for tasks that simpler HTML or CSS could have handled.

Large JavaScript applications could become difficult to maintain.

Visitors might need to download substantial amounts of code before a page became usable.

Accessibility, performance, search-engine visibility, and reliability could suffer if applications were poorly designed.

The lesson is similar to one we encountered with server infrastructure:

The fact that we can add complexity does not mean we should.

Progressive Enhancement

One approach to responsible web development is known as progressive enhancement.

The basic idea is to begin with a solid foundation that works broadly and then add enhanced capabilities where appropriate.

HTML provides meaningful structure.

CSS provides presentation.

JavaScript adds behavior.

If JavaScript is not required for a task, sometimes the best JavaScript is no JavaScript at all.

Use the technology when it improves the experience.

JavaScript and Accessibility

JavaScript can greatly improve accessibility when used carefully.

It can also create serious accessibility problems when developers replace standard browser behavior with custom interactions that do not properly support keyboards, screen readers, focus management, or semantic meaning.

A clickable JavaScript element is not automatically equivalent to a properly constructed HTML button or link.

Understanding HTML remains important even in highly interactive applications.

The technologies work best when they cooperate rather than unnecessarily replacing one another.

JavaScript and Security

Allowing downloaded code to execute inside a browser obviously raises security questions.

Browsers therefore place JavaScript inside a restricted environment commonly described as a sandbox.

JavaScript normally cannot simply browse through every file on a visitor's computer or perform arbitrary operating-system actions.

Browsers enforce boundaries and permissions.

Web security mechanisms also attempt to control how scripts from different websites and origins interact.

As always, however, powerful technology creates new attack possibilities as well as useful capabilities.

Cross-Site Scripting

One of the most important web application vulnerabilities became known as Cross-Site Scripting, usually abbreviated XSS.

If a website improperly handles untrusted input, an attacker may be able to cause JavaScript to execute in another visitor's browser within the context of that website.

This demonstrates an important security principle:

Data must remain data unless we intentionally treat it as code.

Input validation, proper output encoding, browser security features, and careful application design all help defend against these attacks.

JavaScript Became Part of the Web Platform

Modern JavaScript does much more than change text on a page.

Through browser APIs, it can interact with audio, video, graphics, cameras, microphones, location services, local storage, network requests, notifications, clipboard functions, and many other browser capabilities—with security and permission restrictions around sensitive features.

The browser has evolved into an extraordinarily capable computing platform.

JavaScript is one of the primary ways developers communicate with that platform.

A Remarkable Transformation

Consider the journey.

In 1995, JavaScript was created quickly to make Netscape web pages more interactive.

It became standardized as ECMAScript.

It survived the browser wars.

It powered Dynamic HTML.

AJAX allowed pages to communicate with servers without completely reloading.

jQuery made browser scripting easier.

Faster JavaScript engines made increasingly complex applications possible.

Node.js carried JavaScript onto the server.

Modern frameworks helped create application-scale interfaces.

And JavaScript became one of the fundamental technologies of modern computing.

From Ten Days to More Than Thirty Years

JavaScript's origin is sometimes used as a joke.

How could such an important language have been created in approximately ten days?

But perhaps the more interesting lesson is what happened afterward.

The first version did not need to be perfect.

It needed to solve a useful problem.

Then millions of developers, standards contributors, browser engineers, companies, and open-source projects spent decades extending and improving what began there.

Technology does not always arrive fully formed.

Sometimes it grows because people keep finding new things to do with it.

The Browser Learned to Think

HTML allowed the browser to understand a document.

CSS allowed the browser to understand how that document should be presented.

JavaScript gave developers a way to tell the browser what to do.

A document could now react.

It could calculate.

It could communicate.

It could change itself.

It could become an application.

The web had learned to do much more than display pages.

Next: JavaScript Today and Tomorrow

JavaScript survived the browser wars and grew far beyond its original purpose.

But what does JavaScript look like today?

Do modern websites still need jQuery?

When should we use ordinary JavaScript instead of a framework?

What are React, Vue, Angular, Node.js, TypeScript, npm, and all the other names surrounding modern JavaScript?

Why can excessive JavaScript make a website slower or less accessible?

How are modern browser capabilities changing what JavaScript can do?

And what happens when artificial intelligence begins writing much of the JavaScript for us?

Next in The Technologies That Built the Web, we will explore JavaScript Today and Tomorrow—and ask how a language created in approximately ten days became something the modern web can scarcely imagine living without.