In which languages ​​are JavaScript engines written


JavaScript celebrates its 20th birthday

A brief history of JavaScript

When JavaScript was invented in 1995, there was no telling that the language would one day become the leading programming language on the web. Extensive applications in the browser, on the server, on the desktop and on the mobile device are now written in JavaScript. How did this come about, which steps were necessary and how will it go on?

The invention 20 years ago

In the mid-1990s, Netscape Navigator became the first major commercial web browser to hit the market. Version 2.0 contained the first JavaScript interpreter that Brendan Eich had developed in just 10 days. JavaScript should be a simple way of executing program code on a web page compared to Java applets. The possibilities of the first runtime environment were very limited, but already offered dynamic access to the HTML document, which was later standardized in the Document Object Model (DOM).

First standardization as ECMAScript

Microsoft, the great competitor of Netscape, quickly recognized the usefulness of JavaScript and built its own JavaScript engine for its Internet Explorer 3.0 under the name JScript. The two companies joined forces to standardize the core language of JavaScript. The TC39 working group was set up at the standards organization Ecma International, which in June 1997 approved the first version of ECMAScript (ECMA-262). Even today, the TC39 is largely responsible for the further development of JavaScript.

ECMAScript forms the core of JavaScript - a cross-platform, universal programming language. The browser and HTML-specific interfaces, on the other hand, were largely developed and standardized by the World Wide Web Consortium (W3C). The separation into the language core (ECMAScript) and the so-called host environment (e.g. the browser with HTML DOM) was important as early as 1995, because Netscape also used JavaScript on the server side. It later enabled JavaScript to take off outside the browser.

Ajax and the renaissance of JavaScript

After the ECMAScript Edition 3 appeared in 1999, it became quiet about the language core. It was only with the further development of the browser and the DOM interface around 2005 that JavaScript gained momentum. "Ajax" was on everyone's lips. The technology made it possible to load content via JavaScript in the background. For the first time, dynamic interfaces were created in the browser without plugins and server round trips.

From there on, the use of JavaScript exploded. JavaScript libraries and frameworks like Prototype.js, jQuery, and Dojo were springing up. More and more JavaScript was being delivered to the browser. More and more people were taking a serious look at JavaScript.

Meanwhile, the shooting star enjoyed a dubious reputation with the developers. For newcomers, JavaScript did not offer a clear structure, but rather came up with nasty surprises. The language was comparatively inaccessible and unconventional. The remarkable flexibility unfortunately also meant a lack of orientation for learners. Douglas Crockford described JavaScript as the "most misunderstood language in the world" back in 2001, only to add in 2008 that it had now become the most popular language in the world.

Crockford was always concerned with perceiving JavaScript as an independent language, improving its understanding and becoming aware of its strengths. Crockford observed at Yahoo how JavaScript was used in a commercial environment and what problems it encountered. In his book "JavaScript: The Good Parts" from 2008 he named both outstanding skills and weaknesses by name. The aim was to establish a JavaScript practice that would enable the robust development of large applications. His commitment contributed to resuming work on the ECMAScript language core and addressing the practical problems of large JavaScript applications.

Further development of ECMAScript

In 2006 and 2007, work was initially carried out on ECMAScript 4 (PDF in the Web Archive). A significant expansion was planned, which should contain well-known constructs from other programming languages ​​- including declarative classes, interfaces, namespaces and static typing. Although these ideas were successfully implemented in the related languages ​​Microsoft JScript.NET and Adobe ActionScript 3.0, the radical reorganization went too far for some in the TC39 working group. They feared compatibility problems with existing code (especially on the web) and existing engines. There was also the risk that JavaScript would lose its peculiar character as a functional, dynamic, prototype-based language as a result of the extension.

ECMAScript 5 makes development robust

The differences of opinion meant that the planned Edition 4 was discarded and work was initially carried out on a downward-compatible version with cautious innovations. ECMAScript Edition 5, published in December 2009, corrected numerous errors and eliminated pitfalls that had made life difficult. Various useful methods have also been added. New array methods, for example, strengthen the character of JavaScript as an object-oriented language with functional elements (e.g.,,).

The most important ECMAScript 5 innovation is the strict mode, which is switched on with. JavaScript behaves differently in this mode: Unwanted behavior has been corrected or deactivated. For example, an assignment within a function no longer creates a global variable. The keyword is no longer automatically resolved to the global object (in the browser). Both were potential sources of error and caused misunderstandings. In order to regulate access to objects, properties in ECMAScript 5 can be marked as read-only. Entire objects can be "sealed" or even "frozen".

The aim of ECMAScript 5 was the careful correction of conceptual errors and inconsistencies in the language and its implementations, the improvement of the metaprogramming and the selective expansion of the core types. Commercial JavaScript development should become more secure and robust. Since the strict mode requires an opt-in in the code, downward compatibility was guaranteed.

The big change: ECMAScript 6 »Harmony«

The radical restructuring planned since the beginning of the 2000s and thus the expansion of the syntax has been postponed to the next version with the code name »Harmony«. In June 2015, ECMAScript 6 was finally adopted, also called ECMAScript 2015.

Although the new language constructs go back to the drafts for JavaScript 2.0 / ECMAScript 4 that were more than 10 years old, there are two influences that have contributed significantly to the development of ECMAScript 6.

Node.js brings JavaScript to servers and desktops

After Google released the Chrome browser with the new V8 JavaScript engine in 2008, the V8-based server-side JavaScript environment Node.js. was created in 2009. An extensive software ecosystem developed that had a lasting influence on the standardization process and also the client-side JavaScript programming. The pioneering technologies include asynchronous input and output, streams, the CommonJS module system and the node package manager (npm).

Metal languages ​​show the way

At around the same time, metalanguages ​​were created that were translated into JavaScript (ECMAScript 3). CoffeeScript and TypeScript in particular demonstrated how the JavaScript syntax could be extended and simplified. Many of CoffeeScript's new language features, such as class declarations, could easily be translated into ECMAScript-3 code. This "syntax sugar" proved to be useful in practice and increased productivity. CoffeeScript also incorporated numerous best practices from the "Good Parts". Well-known companies preferred CoffeeScript instead of "naked" JavaScript.

ECMAScript 6 paves the beaten track

ECMAScript 6 is a synthesis of these ideas. Instead of creating an ideal language on the drawing board, existing practices were incorporated. "Paving the cowpaths" is what it means in the jargon of web standards. ECMAScript 6 contains a declarative module system that can be seen as a further development of CommonJS. It adopts syntaxes that have proven themselves in CoffeeScript, e.g. declarative classes as syntax sugar for constructors and prototypes as well as an abbreviation for functions.

In the course of this, the ECMAScript 6 syntax corrects further design errors and eliminates pitfalls. With and, variables or constants are possible whose validity (scope) is limited to a block instead of a function. The compact arrow functions (as well as) result in a lexical resolution of the keyword - the cumbersome manual binding of the function is no longer necessary.

ECMAScript 6 in practice

With ECMAScript 6, a great success has been achieved that will shape the next few years. Large projects are already migrating to ECMAScript 6. It is true that no JavaScript engine fully supports the new standard, which appeared just five months ago. It will be years before most of the browsers used on the web support ECMAScript 6 natively.

However, it has become common practice to use the Babel transpiler and a module bundler such as browserify or Webpack to write ECMAScript 6 code and translate it into ECMAScript 5. This practice was perfected by the said metalanguages.

Asynchrony with ECMAScript 6 and 7

JavaScript has come a long way, has come of age, and has been cleaned up of conceptual weaknesses. ECMAScript 6 and the npm ecosystem stand for productivity, robustness, versatility and fun while developing. The further development does not rest, but continues in great strides.

A great strength of JavaScript has always been the asynchronous programming, e.g. of input and output operations (e.g. HTTP requests, database queries). Callback functions are usually used to deal with success and failure. As soon as multiple asynchronous operations are chained, this technique is cumbersome and the code is cluttered.

From promises to

ECMAScript 6 integrates the established Promises standard to simplify working with asynchronous data. A promise is an object that encapsulates a future earnings value and offers prospects. The Promises API can be implemented using ordinary JavaScript. Therefore, the browser support can be retrofitted with polyfills.

Promises make development a lot easier, but they still require separate success and error handling functions. It would be desirable for asynchronous code to be just as easy to write as synchronous, blocking code.

Some try to achieve this goal with generator functions and the yield keyword from ECMAScript 6. But the clean solution is expected to come in ECMAScript 7: The keywords and mark asynchronous functions or function calls. The highlight is: and are just syntax sugar. Ordinary promises are used under the hood, but non-nested notation is possible, as is the case with synchronous code.

Performance limits

With the spread of JavaScript, new requirements were placed on the performance of JavaScript engines. Their manufacturers have been fighting head-to-head for the fastest execution for years. But they are increasingly reaching the limits of the possible optimizations.

JavaScript's dynamic nature and weak typing make it difficult to translate the high-level language code into efficient machine code. Runtime performance is difficult to predict because today's just-in-time compilers optimize the code only when it is executed. The automatic garbage collection interrupts the execution again and again.

These performance limits are particularly evident in mathematical operations that are necessary for 3D games, physics simulations, and audio and video processing.

Reduction and specialization: asm.js and WebAssembly

In order to keep up with the performance of statically typed languages ​​and ahead-of-time compilers, Mozilla developed the asm.js. language as early as 2013. This is a subset of JavaScript that effectively introduces static typing and enables predictable memory management. Asm.js is usually not written by hand, but translated from a high-level language such as C or C ++.

In mid-2015, the four major browser manufacturers announced that they were working together on a further development of asm.js: WebAssembly is a new compressed binary format that contains machine-level program code in the form of an abstract syntax tree. The binary representation saves browsers the parsing step. A separate text representation is planned to ensure readability for people. The commands in this language are extremely limited, the types primitive.

From a technical point of view, WebAssembly has little to do with JavaScript, but is intended to complement JavaScript where it reaches its limits. How JavaScript and WebAssembly relate to one another and how they interlock is still in the stars. What is certain is that web browsers will expand their role as a universal and powerful software platform and that JavaScript will play the central role.