JavaScript is probably one of the most influential programming languages ever. Since the rapid development of the web, JavaScript has reached potential that it was not initially promised. In this article, we shall take a brief look at the entire history of JavaScript from its creation to the present day as well as try to predict its future.
Where It All Started
The circumstances that led to creation of JavaScript unfolded over a six-month period, from May to December 1995. Netscape Communications has been steadily investing in the field of web technologies and already managed to win back positions from NCSA Mosaic, the first popular web browser. Netscape was made by the same professionals who were involved in the development of Mosaic in the early 90s. Now, with funds and certain autonomy, they had everything to start searching for ways to further advance their web technologies. This was the first impulse for founding JavaScript.
Marc Andreessen, founder of Netscape Communications and a leading member of the Mosaic team, was certain that the web should be transformed to become more dynamic and flexible. Animations, user interface, and other types of operability should become an essential part of the Internet of the future. The Web lacked a lightweight scripting language that could work with the DOM, which in those days was not yet modified. There was one consideration that posed a significant challenge at that time: this language should not have been promised for large developers and other people who were related to the engineering side of the industry. Java, back in those days, was already rapidly developing and properly took over this niche. Therefore, the new scripting language was made for an entirely different audience-mainly for designers. No need to mention that the web was still static, and HTML was quite young and easy to master, even for those who had no programming background. Thus, everything that was suggested to become part of the browser and make the web more adjustable has to be as simple as possible for people far from the field. From this premise, the idea of Mocha was introduced, which was to become the simplest, most accessible scripting language.
WIth Mocha, Brendan Eich, the father of JavaScript, appears in our story. Eich was assigned to develop a “Scheme for the browser” for Netscape. Scheme is a powerful and multi-functional dialect of the Lisp programming language with the most simplified syntax. The Web required something as such: user friendly, dynamic, fast, and versatile. Eich was exxcited about the project and was on board with the rest of the team.
The team was tasked with delivering a working prototype as soon as possible. Sun Microsystems was finishing work on its Java programming language, and Netscape Communications was already ready to sign a contract with the company to make Java available in its browser. So why did they need Mocha (the first name of JavaScript)? Why was it important to create a completely new programming language when there was a ready-made option available? Initially, Java was not intended for the audience that Mocha served to-scriptwriters, amateurs, designers. Java was too complex and powerful to take this position. The original idea was that Java should be intended for large developers and professional programmers, while Mocha should be applied for smaller scripting tasks. To put it simply, Mocha was planned as a scripting assistant for Java on a principle similar to how C/C++ and Visual Basic operate on the Windows platform.
Netscape engineers have begun to research Java on a deeper level. They even thought of developing their own Java virtual machine, but the idea was quickly discarded because it could not achieve the same compatibility with the Sun Microsystems virtual machine.
The problem of selecting a language as quick as possible was more critical than ever. Possible nominees were Python, Tcl, and Scheme. Eich had to come up with a decision very quickly. Compared to its competitors, it had two pros: the freedom to determine the set of required capabilities and direct contact with the customer. However, there was also a major con there: lack of time to make a huge number of key decisions. JavaScript, a. k.a. Mocha, was made in such conditions. Within a few weeks, a working prototype was ready to be integrated into Netscape Communicator.
What was supposed to be the analogue of Scheme for the browser, ended up becoming something completely different. Eich’s decision was driven by the need to meet te deadline with Sun and make Mocha a scripting assistant for Java. The syntax was planned to be similar to Java. In addition, Java has inherited denotations for a large number of well-established idioms. So Mocha was very different from Scheme. It looked like Java, but with a combination of Scheme and Self right under the shell.
The Mocha prototype was fully merged into Netscape Communicator in May 1995. After a while, it was renamed and rebranded as LiveScript, because at that time the word “live” looked very appealing from the marketers’ point of view. Later that year, the deal between Netscape Communications and Sun was finalized: Mocha / LiveScript was renamed JavaScript and launched as a scripting language for completing small tasks in the browser, while Java was a fully-featured professional programming language for creating complex web applications.
The very first version of JavaScript already included all the fundamental features that this language is popular for to this day. In particular, its object model and functional traits were already running in the first version.
Many Implementations
When Sun and Netscape sealed the deal, and Mocha/LiveScript finally became JavaScript, a very important concern arose: what will happen to the potential competitors? Even though Netscape was slowly gaining popularity, becoming one of the most used browser, Microsoft was already actively promoting Internet Explorer. From the very beginning, JavaScript had so many things to offer in terms of user interaction that other browsers had to seek ready-made solutions that were basically working implementations of JavaScript. At that time (and for some time after that), web service principle remained the same. Microsoft launched its own JavaScript implementation, naming it JScript. By taking away the word Java from the name, they were able to prevent getting into trouble with the owners of the trademark. Nevertheless, JScript wasn’t just different in its brand. There were various differences in implementation — for instance, the approach to some DOM functions-left ripples that will be there for many years to come. The confrontations for JavaScript were happening on many more fronts than names and timelines, and many of the features of this language came about because of them. The first version of JScript was introduced in Internet Explorer 3.0, which was launched in August 1996.
The JavaScript execution also got its own name in Netscape. The version released with Netscape Navigator 2.0 was known as Mocha. In the fall of 1996, Eich modified most of Mocha to manage certain technical flaws and shortcomings that came as a result of the rush to deliver. The new version was named SpiderMonkey. This name is still used even today in the JavaScript engine of the Firefox browser, the newer version of Netscape Navigator.
For a few years, JScript and SpiderMonkey were the only JavaScript engines. The characteristics of both engines, which are not entirely compatible, have establishes the vector of web development for the coming decades.
Key Aspects of the Architecture
Although it is clear by now that JavaScript was born in a hurry, most of its dynamic features were built into it from the very beginning. These features characterized JavaScript as a language and enabled it to outgrow its own limitations, despite all its disadvantages.
Even if creating a syntax as close to Java as possible was not the main goal of JavaScript, the industry around made its own corrections. Perhaps a different syntax would work better for certain tasks, but due to the use of familiar syntax, JavaScript has easily gained such popularity.
Try comparing this example written in Java:
public class Sample {
public static void main(String[] args) {
System.out.println("Hello world!");
try {
final MissileSilo silo = new MissileSilo("silo.weapons.mil");
silo.launchMissile(args[0]);
} catch(Exception e) {
System.out.println("Unexpected exception: " + e);
}
}
}
with this example made in JavaScript:
console.log('Hello world');
try {
const silo = new MissileSilo('silo.weapons.mil');
silo.launchMissile(process.argv[0]);
} catch(e) {
console.log('Unexpected exception' + e);
}
Managing Functions
Functions in JavaScript should be viewed as another type of object. They can be operated on, as well as any other components. They can be connected to variables and, in later versions of JavaScript, even called in as exceptions. Most likely, this feature of JavaScript came from Scheme. To iilustrate with an example:
var myFunction = function() {
console.log('hello');
}
otherFunction(myFunction);
myFunction.property = '1';
And since functions are considered as objects, different functional patterns have become possible:
var a = [1, 2, 3];
a.forEach(function(e) {
console.log(e);
});
Introducing Prototype Programming
It is without a doubt that prototypical programming became popular because of JavaScript, yet it was first introduced in Self. Eich enjoyed this particular style of programming, which proved good enough to structure the more conventional approach of Simula-like languages such as Java or C++. To a great extent, the classes implemented in the modern version of JavaScript are nothing but mildly transformed prototype system.
The founders of Self, the programming language that led Eich to introduce prototypes to JavaScript, tried to avoid any confusion associated with objects in Simula-like languages. Specifically, branching between classes and instances has led to many problems inherent in Simula-like languages. We have already talked about the problem that arose when the program code developed and became bigger: since classes were the archetype for all new objects, as the code grew bigger, it became significantly difficult to adjust the founding classes to the new standards that came up in the process. This problem can be prevented by introducing new instances of prototypes, from which, in turn, new objects would be produced. This is the main concept of prototypes: a sample that can be coordinated within its own parameters. If the prototype did not match the new object, it could be cloned and edited without involving any other child instances. In class-based languages, this approach could be seriously challenging to implement.
ECMAScript
The first big alteration for JavaScript after its release was the standardization of ECMA. ECMA is an association founded in 1961 to standardize data and directive systems.
Project on standardizing JavaScript commenced in November 1996. The standard that the TC-39 team was working on went by the ECMA-262 identification number. At that time, JavaScript was widely used in many web pages – the 1996 press release shows the number of 300,000 pages running JavaScript.
Standardization has become an important step and a serious challenge to face for such young language. It advertised JavaScript to a larger audience and let third-party developers to join the development of the language. It also helped keep other developers in line as during that time, there was a concern that Microsoft or anyone else might benefit the most from the original implementation of the language, which could potentially lead to fractioning.
Due to certain trademark problems that occured along the way, ECMA could not use JavaScript as the name. After a brief discussion, it was decided that the programming language defined by the standard would be named ECMAScript. Thus, JavaScript is simply a commercial name for ECMAScript.
