JavaScript – History, Trends and Issues

The following article describes the history of JavaScript programming language, explains how modern browsers interpret and execute it, as well as evaluates the present state of the JavaScript technology. The document also focuses on some of the recent developments and trends, briefly covers the current alternatives and brings attention to problems that are closely related to using the language as a tool to develop web base applications.

 History of JavaScript

 JavaScript Engines

 JavaScript Libraries and Frameworks

 Transpiling JavaScript

 JavaScript Issues

Dart – JavaScript Alternative


History of JavaScript

This section covers the history of the JavaScript and explains the reasons for creating the JavaScript language; that is currently one of the most popular programming languages ever created.

JavaScript programming language was introduced in early 1995 by Brendan Eich, at the time working at Netscape Communications Corporation. Most online resources claim that it took Eich only ten days to create the language. The language became an overnight success which propelled Eich to a new career in which he co-founded the Mozilla Corporation, where he currently assumes a role of chief executive officer.

But let’s go back to first days of JavaScript. The initially, within Mozilla, the new JavaScript language was known under the name ‘Mocha,’ which was invented by the founder of Netscape, Marc Andreessen. Later in the fall of 1995, this name was changed to LiveScript, which got then changed to JavaScript in December 1995, when Sun accepted the trademark license request. From then on, the name JavaScript became widely embraced by the community. The name JavaScript fuels the speculations that it was chosen mainly to ride the popularity wave of Java programming language, but we may never find the real reasons for changing the name from LiveScript to JavaScript.

Nevertheless, while most people agree, that the name JavaScript was an excellent marketing move, boosting JavaScript chances to establish its user base, most people would also come to an agreement that the name created a massive confusion, especially among non-programmers. This is due to a very prevalent misconception; that JavaScript is somehow related to Java, which is not the case. There were perhaps some solid reasons for naming the new programming language JavaScript, because we know, Java, same as the JavaScript are both object-oriented programming languages. Brendan Eich somewhat hinted the connection, by stating in 2005, that “JavaScript was conceived of as an “object-based scripting language” (Eich, B., 2005), so perhaps that was the motivation behind borrowing the name from Java. As far as the word ‘Script’ in ‘JavaScript’ goes, it may entice that it’s a simpler and easier to learn the language, which is a correct statement. But in any case, it’s important to remember, that JavaScript is not a script-like version of the Java or any extension of the language that runs on browsers only. The two languages do not share anything in common.

The life of JavaScript started in Netscape Navigator 2, which was one of the hottest web browsers of the time. As the JavaScript gained the popularity, Microsoft became interested in using it in their Internet Explorer browser. However, as Microsoft did not want to deal with trademark and Sun, they decided to call their implementation of JavaScript, using an abbreviation JScript. There is another misconception that JScript and JavaScript are similar languages, but that’s a misapprehension because they are only different names for exactly the same language.

It has become an unfortunate practice, because what started with Microsoft, carried through the industry and other vendors started releasing their own versions of JavaScript, adopting them in their web browsers. As most of us can imagine, different implementations soon started creating problems, in which JavaScript code did not reliably work with various types of browsers.

Later on, the issues between Netscape and Microsoft gave rise to ECMAScript (established by Brendan Eich) that is today regarded as a de facto standard for JavaScript. What is ECMAScript? It’s a project whose goal is to standardize JavaScript among different vendors, such as before mentioned Microsoft JScript and ActionScript. This is a blessing for an end user, because as long as major browser vendors adhere to a standard, we can expect the same level of support for JavaScript no matter which browser is our preferred tool for accessing the websites and web based application.

JavaScript Engines

Now that we’ve covered a little of the history let’s explain how JavaScript works inside the browser.

“Well, to let you in on a secret, your computer doesn’t really understand JavaScript. It needs something to interpret the JavaScript code and convert it into something that it understands; hence it is an interpreted language. Computers understand only machine code, which is essentially a string of binary numbers (that is, a string of zeros and ones). As the browser goes through the JavaScript, it passes it to a special program called an interpreter, which converts the JavaScript to the machine code your computer understands. The important point to note is that the conversion of the JavaScript happens at the time the code is run; and it has to be repeated every time this happens” (Wilton & McPeak, 2010)

Now that we know that the browser needs an interpreter to convert JavaScript to something our computers can understand, it’s probably a good time to note, that each browser that supports JavaScript has its own interpreter and they may vary in performance. The trend to develop the fastest and the best JavaScript interpreter let to a performance evolution enjoyed by all of us today, but as a side effect, also to JavaScript engine race that started in 1996 and last to this day. The race is usually referred to as a Browser War, and various browser vendors came up to the top over the years. As a matter of fact, before what is today called a ‘second browser war’ (dating to 2009), JavaScript engines were simply interpreters that read and executed JavaScript source code, today we refer to interpreters as JavaScript engines, libraries that run JavaScript code. When it comes to performance, in 2009 we’ve seen Chrome on top. Chrome was at the time able to run JavaScript in the fastest manner, but later in 2010 it was Opera Browser, who replaced older Futhark engine with the fast running Carakan, improving execution time and ended up as a winner that year. As of now, towards the end of 2016, it’s. However, Google is again winning the browser war with its open source high-performance JavaScript engine called V8. V8 is written in C++ and used in Google Chrome browser, and today it is the fastest way to interpret the JavaScript in browsers. It’s good to mention perhaps, that V8 engine adheres and “implements ECMAScript as specified in ECMA-262, 3rd edition, and runs on Windows XP or later, Mac OS X 10.5+, and Linux systems as well. V8 can also run standalone, or can be embedded into any C++ application.” (Chrome V8, 2016)

Those interested in seeing the performance of V8 engine and other JavaScript engines can visit one of numerous benchmark projects, such as up-to-date browser benchmark comparison at At this website, you’ll be able to see in work also one of the most popular open source reference project that measures a JavaScript engine’s performance called Octane 2, which implements a suite of tests that are representative of today’s complex and demanding web applications.

As of November 2016, it lists the TurboFan (Google V8’s new compiler used in Chrome browser) as the fastest JavaScript engine:


Octane project is available on Github, allowing anyone to test their browser directly by running the benchmark application from any browser (viisit:


One of the best resources I’ve found, that shows ECMAScript 5, 6, and 2016+ compatibility table is available from the following URLs:

ECMAScript 6 compatibility table

ECMAScript 5 compatibility table

ECMAScript 2016+ compatibility table

Following is an excerpt from ES6 compatibility table, which shows how among desktop browser Chrome is really unmatched in terms of their conformity to the ES6 standard. As we can see, Chrome browser is 97% compatible with ES6 standard ever since the version 54 (and now we’re at 57). The only other browser which is getting to the levels of Chrome, is Firefox vs 53 nightly package at 96% (so not something that is available to general public as a default FireFox download). Microsoft is lacking at 11% with their IE 11, but doing slightly better with 93% support for the latest version of MS Edge 14 browser.



JavaScript Libraries and Frameworks

There are many JavaScript libraries and frameworks available on the market, but they share something in common, which is already suggested by the name itself. And that is, that JavaScript frameworks are just a set of tools written in JavaScript. So they’re not the programming languages themselves (a common misconception) but rather only the extensions of the JavaScript.

So, what do we need JavaScript libraries and frameworks? The reason for the existence of JavaScript frameworks is unpretentious; they’re here mainly in order to simplify the lives of JavaScript developers.

JavaScript libraries come with a lot of useful, conveniently predefined functions and utilities; that can save the development time, and improve the web application.

When it comes to JavaScript frameworks, they go even further, taking the concept I just described to another more advanced level. Frameworks in general (not just JavaScript frameworks) allow developers to structure their application in a more efficient manner, providing them with better ways to organize the code, making their apps more elastic, scalable, accessible and easier to work with and support. JavaScript frameworks are not different.

When we’re referring to JavaScript frameworks, in most cases, they’re based on the MVC architectural pattern. The MVC or Model View Controller architecture splits an application into three focal components, which as the name suggests are the following elements: the model, the view, and the controller. The benefit of MVC comes from its ability to isolate the complexity of the web application and allows us to simplify the development.

As of 2016, there are currently over 50 different JavaScript frameworks. Some famous examples of a JavaScript framework that use MVC architecture are AngularJS, which is using MVC pattern called MVVC – Model, View, View Controller, as outlined in the following image:

© Dmitry Ivashutin, 2014

AngularJS, is now being replaced by Angular 2, who’s MVC pattern is now called MV* (for Model-View-Everything) or it’s also referred to, as MVW (for Model-View-Whatever), which in case of Angular2 simply hints at the use of component based architecture, because in Angular2 we can create everything in a similar fashion to a way we create a typical component. That includes services, directives, pipes, etc., even though they only provide a support of the base component.

© Sudhaa Gopinath, 2014

So, the name MVW or MV* merely provides a suggestion, that Angular 2 effectively handles the separation of concerns by separating presentation logic from business logic and presentation state.

Angular’s main competitors are Ember.js, React and Google Web Toolkit (whose Java code in transpiled to JavaScript). Among libraries, the most know is a cross-platform jQuery library, which captured the hearts of millions of developers, mainly for its modular approach to making dynamic web applications.

I’d like to add here, that Angular 2 is catching up with Angular 1.x extremely quickly. Please check the Igor Minar video, where he explains it @Devoxx:

Here is a screenshot from the video:


And following is a trends screenshot for a comparison of Angular 1 and Angular 2 as of Nov 22:

As you can see Angular 2 user base is growing quickly:



Transpiling JavaScript

Another trend that is currently a very popular one, and preferred by almost everyone who uses Angular2 to create web application, is to use TypeScript instead of JavaScript.

What is TypeScript?

TypeScript is one of the highest quality transpilers of JavaScript currently available. What does it do? Well, TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. Its biggest advantage lies in providing Object Oriented programming concepts on top of JavaScript, such as static checking, modules, interfaces all the way to classes, etc. Of course, browsers don’t yet support TypeScript natively, so the final code needs to be transpiled to auto-generated ES3+ idiomatic JavaScript, but that’s expected.

You may ask if TypeScript would still enjoy the populatiry after the ES7 or future ES8 is widely adopted. That would be a valid question. In my opinion, it’s very likely that TypeScript will remain in front of ESx mostly because of the problems with widespread ESx browser support.

And there are other advantages, such as OOP nature of the TypeScript, for which it is considered a lot better option then going with writing a plain old JavaScript. And as the process of transpiling isn’t taking anything away, in fact it allows the language to adhere to ECMA standards, it pretty much guarantees that the code will run on every browser (down to IE9 if you believe it) and on any operating system. Additionally, it allows developers to use the latest and evolving JavaScript features.

JavaScript Security

The most commonly recognized problem of JavaScript is a propensity to create a disordered and hard-to-maintain code. The problem is not related to the language itself, but rather to tendencies among JavaScript programmers who use the language and often create solutions which untidy and chaotic.

It’s said that “JavaScript, although object-oriented, does not take the concept of a class hierarchy and inheritance to heart” (Kopec D., 2014), which is likely responsible for most of the disadvantages experienced with JavaScript. Additionally, the issues are also likely related to the vast user base and community that uses JavaScript. As nearly everyone has a website today, almost everyone is also trying to implement some JavaScript on their site. That said, the level of experience among developers varies more than with any other language. Advantages of alternative languages, such as previously mentioned Dart are in the structure of the language, which makes it harder to write a messy code.

The problems with a messy coded JavaScript are mainly due to a huge volume of malware that is looking for specific common mistakes in the implementation of JavaScript. That said, “JavaScript, the dominant scripting language for web applications, is the primary channel for most of these attacks.” (Ofuonye, E. and Miller, J., 2008)

One of the biggest security issues is cross-site scripting. I’ve ended up looking and reading one of the online resources at – and it is a very good source of information. I highly recommend that article to anyone that would like to find little more on the topic of cross-site scripting. Following is my attempt at outlining the risks and compile a simply to read list. As you can see, it’s pretty scary what can be done JavaScript. Injecting malicious JavaScript would provide attacker with access to the same objects the rest of the web page has, and that includes:

– Browser Cookies

– User Session Cookie (it could iimpersonate user)

– Modify DOM (do any modifications to page it)

– Send HTTP requests to any destination (by using XMLHttpRequest)

– Get access to user’s geolocation, webcam, microphone and files from the user’s file system (by using HTML5 APIs)

A clever attacker can go a long way!


Dart – JavaScript Alternative

As of now, the majority of modern browsers only support JavaScript. However, there seems to be a motion taking place for browsers to support a new general-purpose programming language called Dart. Dart is developed by Google and already approved as a standard by Ecma. Dart is an open-source software licensed under BSD, which allows developers to build the web application, as well as mobile and server apps, including IoT devices.

David Kopec, in his 2014 book ‘Dart For Absolute Beginners’, states the following advantages of Dart over JavaScript: “Dart is a new, relatively easy-to-learn programming language from Google. JavaScript, the main client-side programming language used on the Web, is regarded by many to contain some fundamental flaws that have persisted through several revisions of the language. Dart was developed as a fresh start. The 2014 statistics show native Dart to be approximately two times faster than JavaScript.” (Kopec D., 2014)

As good as the statement above dated to 2014 may sound, as of 2016, the only browser that supports Dart out of the box is a Chromium web browser. Chromium browser is capable of doing this because it natively ships with a Dart virtual machine (VM), that can execute the Dart code directly in the browser.

If all browsers supported Dart, it would probably become a huge competitor to JavaScript. Unfortunately, as good as the language may be, that’s not the case. Chromium is not a favorite web browser, and because other vendors did not start including Google’s Dart VM in their browsers, Google eventually decided to cancel also its own support for Dart in Chrome (Note: Chrome and Chromium are different browsers). It was regarded as a somewhat unfortunate move, because the language has many advantages and is also already widely adopted in Google projects such as Google Fiber, Google Express, etc.

Fortunately, that doesn’t mean that Dart is dead because Dart language does not need to run directly in the web browser; it can also be converted back to JavaScript, meaning that any of the modern web browsers can easily execute Dart programs. But that also means that we cannot think of Dart as a competitor to JavaScript and we may not see the Dart becoming the future of the Web, as Google and many of the Dart fans had certainly hoped for. For now, JavaScript is the winner of this race.

Other trends?

I know this will be a bit outside of what we’re generally commenting on here, but it talks JavaScript trends and I thought it’s a pretty cool idea, something new.

As we all know, JavaScript is an incredible language. It’s smart, it’s powerful, and we wouldn’t have any dynamic websites around if it weren’t for JavaScript.  And with that comes a whole new realm, where people start exploring ideas, such as, why not write everything in JavaScript.

Does it sound mad to you? Why? Initially, JavaScript was only for the front-end, then people started using it to code a backend as well (and it’s getting ever so popular). Then Facebook launched JSX that is a preprocessor step that adds XML syntax to JavaScript (it’s merging HTML markup with JavaScript) and now this guy is coming up with doing not just that but also include CSS into the mix.

Isn’t that an excellent idea? Hm, I am curious. Well, this idea was conceived a couple of months ago by Krasimir Tsonev and it’s called CSSX.

“CSSX is a set of tools that will help you write vanilla CSS in JavaScript.” (CSS in JavaScript, 2016)

I am not sure if it will ever catch anyone’s attention, there is certainly not that many contributors to this project, but I found it kind of cool. Please take a look at the following Github url:

What I like about the project is, that “CSSX is not only about writing vanilla CSS in JavaScript. Even though you get this, the main idea here is to have a good API for managing styles. CSSX doesn’t inline styles, so you keep your markup clean. It works directly with injected stylesheets. ” (Krasimir, 2016)

Here is a short example:


This is an open end to this article. Don’t hesitate to send me your comments.




Wilton, P, & McPeak, J 2010, Beginning Javascript. [Electronic Book], n.p.: Hoboken, NJ : Wiley, c2010., University of Liverpool Catalogue, EBSCOhost, viewed 21 November 2016.

Kopec, D 2014, Dart For Absolute Beginners. [Electronic Book], n.p.: Berkeley, CA : Apress, 2014., University of Liverpool Catalogue, EBSCOhost, viewed 21 November 2016.

Ofuonye, E. and Miller, J., 2008, November. Resolving javascript vulnerabilities in the browser runtime. In 2008 19th International Symposium on Software Reliability Engineering (ISSRE) (pp. 57-66). IEEE, viewed 21 November 2016.

A short history of JavaScript (2016) Available at: (Accessed: 21 November 2016).

Eich, B., 2005, September. JavaScript at ten years. In ACM SIGPLAN Notices (Vol. 40, No. 9, pp. 129-129). ACM.

Chrome V8 (2016) Available at: (Accessed: 21 November 2016).

Gopinath, S. (2015) AngularJS-Superheroic JavaScript MVW framework. Available at: (Accessed: 22 November 2016).

Is angular2 mvc? (2016) Available at: (Accessed: 22 November 2016).

Will typeScript have a purpose after ES6/ES7 is widely adopted? (2016) Available at: (Accessed: 22 November 2016).

Green, B. (2016) TypeScript – JavaScript that scales. Available at: (Accessed: 6 November 2016).

Acunetix (2016) What is cross-site Scripting and how can you fix it?. Available at: (Accessed: 25 November 2016).

Krasimir (2016) Krasimir/cssx. Available at: (Accessed: 30 November 2016).

CSS in JavaScript (2016) Available at: (Accessed: 30 November 2016).

(Visited 40 times in last 30 days)