Over a million developers have joined DZone.

A Brief History of JavaScript (Part 1)

DZone's Guide to

A Brief History of JavaScript (Part 1)

JavaScript is arguably one of the most important languages today. The rise of the web has taken JavaScript places it was never conceived it would go. Let's take a look at how JavaScript has evolved in its short history and where it is headed next. Read on!

· Web Dev Zone
Free Resource

Add user login and MFA to your next project in minutes. Create a free Okta developer account, drop in one of our SDKs to your application and get back to building.

JavaScript is arguably one of the most important languages today. The rise of the web has taken JavaScript places it was never conceived it would go. Let's take a look at how JavaScript has evolved in its short history and where it is headed next. Read on!

It All Began in the 90's

It all happened in six months from May to December 1995. Netscape Communications Corporation had a strong presence in the young web. Its browser, Netscape Communicator, was gaining traction as a competitor to NCSA Mosaic, the first popular web browser. Netscape was founded by the very same people that took part in the development of Mosaic during the early 90s, and now, with money and independence, they had the necessary freedom to seek further ways to expand the web. And that is precisely what gave birth to JavaScript.

Netscape Logo

Marc Andreessen, founder of Netscape Communications and part of the ex-Mosaic team, had the vision that the web needed a way to become more dynamic. Animations, interaction and other forms of small automation should be part of the web of the future. So the web needed a small scripting language that could interact with the DOM (which was not set in stone as it is right now). But, and this was an important strategic call at the time, this scripting language should not be oriented to big-shot developers and people with experience in the software engineering side of things. Java was on the rise as well, and Java applets were to be a reality soon. So the scripting language for the web would need to cater to a different type of audience: designers. Indeed, the web was static. HTML was still young and simple enough for non-developers to pick up. So whatever was to be part of the browser to make the web more dynamic should be accessible to non-programmers. And so the idea of Mocha was born. Mocha was to become a scripting language for the web. Simple, dynamic, and accessible to non-developers.

Image title

Marc Andreesen

This is when Brendan Eich, father of JavaScript, came into the picture. Eich was contracted by Netscape Communications to develop a "Scheme for the browser". Scheme is a Lisp dialect and, as such, comes with very little syntactic weight. It is dynamic, powerful, and functional in nature. The web needed something of the sort: easy to grasp syntactically; dynamic, to reduce verbosity and speed up development; and powerful. Eich saw a chance to work on something he liked and joined forces.

Brendan Eich

Brendan Eich

At the moment there was a lot of pressure to come up with a working prototype as soon as possible. The Java language, née Oak at the time, was starting to get traction. Sun Microsystems was making a big push for it and Netscape Communications was about to close a deal with them to make Java available in the browser. So why Mocha (this was the early name for JavaScript)? Why create a whole new language when there was an alternative? The idea at the time was that Java was not suited for the type of audience that would consume Mocha: scripters, amateurs, designers. Java was just too big, too enterprisy for the role. So the idea was to make Java available for big, professional, component writers; while Mocha would be used for small scripting tasks. In other words, Mocha was meant to be the scripting companion for Java, in a way analogous to the relationship between C/C++ and Visual Basic on the Windows platform.

At the moment this was all going on, engineers at Netscape started studying Java in detail. They went so far as starting to develop their own Java Virtual Machine. This VM, however, was quickly shot down on the grounds that it would never achieve perfect bug-for-bug compatibility with Sun's, a sound engineering call at the time.

There was a lot of internal pressure to pick one language as soon as possible. Python, Tcl, Scheme itself were all possible candidates. So Eich had to work fast. He had two advantages over the alternatives: freedom to pick the right set of features, and a direct line to those who made the calls. Unfortunately, he also had a big disadvantage: no time. Lots of important decisions had to be made and very little time was available to make them. JavaScript, a.k.a. Mocha, was born in this context. In a matter of weeks a working prototype was functional, and so it was integrated into Netscape Communicator.

What was meant to be a Scheme for the browser turned into something very different. The pressure to close the deal with Sun and make Mocha a scripting companion to Java forced Eich's hand. A Java-like syntax was required, and familiar semantics for many common idioms was also adopted. So Mocha was not like Scheme at all. It looked like a dynamic Java, but underneath it was a very different beast: a premature lovechild of Scheme and Self, with Java looks.

The prototype of Mocha was integrated into Netscape Communicator in May 1995. In short time, it was renamed to LiveScript. At the moment, the word "live" was convenient from a marketing point of view. In December 1995, Netscape Communications and Sun closed the deal: Mocha/LiveScript would be renamed JavaScript, and it would be presented as a scripting language for small client-side tasks in the browser, while Java would be promoted as a bigger, professional tool to develop rich web components.

This first version of JavaScript set in stone many of the traits the language is known for today. In particular, its object-model, and its functional features were already present in this first version.

It is hard to say what would have happened had Eich failed to succeed in coming up with a working prototype in time. Working alternatives were not Java-like at all. Python, Tcl, Scheme, were very different. It would have been difficult for Sun to accept a companion language to Java that was so different, or that predated Java itself in history and development. On the other hand, Java was for a long time an important part of the web. Had Sun never been part of the equation, Netscape could have exercised more freedom at picking a language. This is true. But would Netscape have opted to adopt an external solution when an internally controlled and developed was possible? We will never know.

Different Implementations

When Sun and Netscape closed the deal to change the name of Mocha/LiveScript to JavaScript a big question was raised: What would happen to alternative implementations? Indeed, although Netscape was quickly becoming the preferred browser at the time, Internet Explorer was also being developed by Microsoft. From the very first days, JavaScript made such a considerable difference in user experience that competing browsers had no choice but to come up with a working solution, a working implementation of JavaScript. At the moment (and for a very long time), web standards were not strong. So Microsoft implemented their own version of JavaScript, called JScript. Keeping "Java" off the name avoided possible trademark issues. However, JScript was different in more than just name. Slight differences in implementation, in particular with regards to certain DOM functions, caused ripples that would still be felt many years into the future. JavaScript wars were fought in more fronts than just names and timelines and many of its quirks are just the wounds of these wars. The first version of JScript was included with Internet Explorer 3.0, released in August 1996.

Netscape's implementation of JavaScript also received an internal name. The version released with Netscape Navigator 2.0 was known as Mocha. In the fall of 1996, Eich rewrote most of Mocha into a cleaner implementation to pay off for the technical debt caused by rushing it out of the door. This new version of Netscape's JavaScript engine was called SpiderMonkey. SpiderMonkey is still the name of the JavaScript engine found in Firefox, Netscape Navigator's grandson.

For several years, JScript and SpiderMonkey were the premier JavaScript engines. The features implemented by both, not always compatible, would define what would become of the web in the following years.

Major Design Features

Although JavaScript was born in a hurry, several powerful features were part of it from the beginning. These features would define JavaScript as a language, and would allow it to outgrow its walled garden in spite of its quirks.

Whether any existing language could be used, instead of inventing a new one, was also not something I decided. The diktat from upper engineering management was that the language must “look like Java”. That ruled out Perl, Python, and Tcl, along with Scheme. Later, in 1996, John Ousterhout came by to pitch Tk and lament the missed opportunity for Tcl. 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. - Brendan Eich's blog: Popularity

Java-like Syntax

Although keeping the syntax close to Java was not the original idea behind JavaScript, marketing forces changed that. In retrospective, although a different syntax might have been more convenient for certain features, it is undeniable that a familiar syntax has helper JavaScript gain ground easily.

Compare this Java example:

public class Sample {
  public static void main(String[] args) {
    System.out.println("Hello world!");
    try {
      final MissileSilo silo = new MissileSilo("silo.weapons.mil");
    } catch(Exception e) {
      System.out.println("Unexpected exception: " + e);

To this (modern) JavaScript example:

console.log('Hello world');
try {
  const silo = new MissileSilo('silo.weapons.mil');
} catch(e) {
  console.log('Unexpected exception' + e);

Functions as First-Class Objects

In JavaScript, functions are simply one more object type. They can be passed around just like any other element. They can be bound to variables, and, in later version of JavaScript, they can even be thrown as exceptions. This feature is a probable result of the strong influence Scheme had in JavaScript development.

var myFunction = function() {
myFunction.property = '1';

By making function first-class objects, certain functional programming patterns are possible. For instance, later versions of JavaScript make use of certain functional patterns:

var a = [1, 2, 3];
a.forEach(function(e) {

These patterns have been exploited to great success by many libraries, such as underscore and immutable.js.

Prototype-based Object Model

Althought the prototype-based object model was popularized by JavaScript, it was first introduced in the Self language. Eich had a strong preference for this model and it is powerful enough to model the more traditional approach of Simula-based languages such as Java or C++. In fact, classes, as implemented in later version of JavaScript, are nothing more than syntactic sugar on top of the prototype system.

One of the design objectives of Self, the language that inspired JavaScript's prototypes, was to avoid the problems of Simula-style objects. In particular, the dichotomy between classes and instances was seen as the cause for many of the inherent problems in Simula's approach. It was argued that as classes provided a certain archetype for object instances, as the code evolved and grew bigger, it was harder and harder to adapt those base classes to unexpected new requirements. By making instances the archetypes from which new objects could be constructed, this limitation was to be removed. Thus the concept of prototypes: an instance that fills in the gaps of a new instance by providing its own behavior. If a prototype is deemed inapropiate for a new object, it can simply be cloned and modified without affecting all other child instances. This is arguably harder to do in a class-based approach (i.e. modify base classes).

function Vehicle(maxSpeed) {
    this.maxSpeed = maxSpeed;

Vehicle.prototype.maxSpeed = function() {
    return this.maxSpeed;

function Car(maxSpeed) {
    Vehicle.call(this, maxSpeed);

Car.prototype = new Vehicle();

The power of prototypes made JavaScript extremely flexible, sparking the development of many libraries with their own object models. A popular library called Stampit makes heavy use of the prototype system to extend and manipulate objects in ways that are not possible using a traditional class-based approach.

Prototypes have made JavaScript appear deceptively simple, empowering library authors.

A Big Quirk: Primitives vs Objects

Perhaps one of the biggest mistakes in the hurried development of JavaScript was making certain objects that behave similarly have different types. For instance, the type of a string literal ("Hello world") is not identical to the type of the String object (new String('Hello world')). This sometimes enforces unnecesarry and confusing typechecks.

> typeof "hello world"
< "string"

> typeof new String('hello world')
< "object"

But this was just the start in JavaScript history. Its hurried development made certain design mistakes a possibility much too real. However, the advantages of having a language for the dynamic web could not be postponed, and history took over.

The rest is perverse, merciless history. JS beat Java on the client, rivaled only by Flash, which supports an offspring of JS, ActionScript. - Brendan Eich's blog: Popularity

A Trip Down Memory Lane: A Look at Netscape Navigator 2.0 and 3.0

The first public release of JavaScript was integrated in Netscape Navigator 2.0, released in 1995. Thanks to the wonders of virtualization and abandonware websites, we can revive those moments today!

Netscape Navigator 2.01 Gold

Unfortunately, many basic features of JavaScript were not working at the time. Anonymous functions and prototype chains, the two most powerful features, were not working as they do today. Still, these features were alredy part of the design of the language and would be implemented correctly in the following years. It should be noted that the JavaScript interpreter in this release was considered in alpha state.

Image title

Fortunately, a year later, Netscape Navigator 3.0, released in 1996, was already making a big difference:

Image title

Note how the error gives us more information about what is going on. This lets us speculate the interpreter is treating the prototype property in a special way. So we attempt to replace the object with a basic Object instance which we then modify. Et voilá, it works! Somewhat, at least. The assignment inside the test function appears to do nothing. Clearly, there was a lot of work that needed to be done. Nonetheless, JavaScript in its state was usable for many tasks and its popularity continued growing.

Features such as regular expressions, JSON, and exceptions were still not available. JavaScript would evolve tremendously in the following years...

Stay tuned for part 2, coming soon.

Launch your application faster with Okta’s user management API. Register today for the free forever developer edition!

standard ,new ,features ,ecmascript

Published at DZone with permission of Sebastián Peyrott, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}