April 2002 Draft JavaScript 2.0 Introduction Motivation

Tuesday, October 9, 2001

Goals

The main goals of JavaScript 2.0 are:

• Making the language suitable for writing modular and object-oriented applications
• Making it possible and easy to write robust and secure applications
• Improving upon JavaScript’s facilities for interfacing with a variety of other languages and environments
• Improving upon JavaScript’s reflection and dynamic capabilities
• Improving JavaScript’s suitability for writing applications for which performance matters
• Defining support for threads and robust sharing of facilities among threads and/or runtimes
• Simplifying the language where possible
• Keeping the language implementation compact and flexible

The following are specifically not goals of JavaScript 2.0:

• Making JavaScript 2.0 suitable for all programming tasks
• Making JavaScript 2.0 similar to any existing programming language

JavaScript is not currently an all-purpose programming language. Its strengths are its quick execution from source (thus enabling it to be distributed in web pages in source form), its dynamism, and its interfaces to Java and other environments. JavaScript 2.0 is intended to improve upon these strengths, while adding others such as the abilities to reliably compose JavaScript programs out of components and libraries and to write object-oriented programs. On the other hand, it is not our intent to have JavaScript 2.0 supplant languages such as C++ and Java, which will still be more suitable for writing many kinds of applications, including very large, performance-critical, and low-level ones.

Rationale

The proposed features are derived from the goals above. Consider, for example, the goals of writing modular and robust applications.

To achieve modularity we would like some kind of a library mechanism. The proposed package mechanism serves this purpose, but by itself it would not be enough. Unlike existing JavaScript programs which tend to be monolithic, packages and their clients are often written by different people at different times. Once we introduce packages, we encounter the problems of the author of a package not having access to all of its clients, or the author of a client not having access to all versions of the library it needs. If we add packages to the language without solving these problems, we will never be able to achieve robustness, so we must address these problems by creating facilities for defining abstractions between packages and clients.

To create these abstractions we make the language more disciplined by adding optional types and type-checking. We also introduce a coherent and disciplined syntax for defining classes and hierarchies and versioning of classes. Unlike JavaScript 1.5, the author of a class can guarantee invariants concerning its instances and can control access to its instances, making the package author’s job tractable. The class syntax is also much more self-documenting than in JavaScript 1.5, making it easier to understand and use JavaScript 2.0 code. Defining subclasses is easy in JavaScript 2.0, while doing it robustly in JavaScript 1.5 is quite difficult.

To make packages work we need to make the language more robust in other areas as well. It would not be good if one package redefined Object.toString or added methods to the Array prototype and thereby corrupted another package. We can simplify the language by eliminating many idioms like these (except when running legacy programs, which would not use packages) and provide better alternatives instead. This has the added advantage of speeding up the language’s implementation by eliminating thread synchronization points. Making the standard packages robust can also significantly reduce the memory requirements and improve speed on servers by allowing packages to be shared among many different requests rather than having to start with a clean set of packages for each request because some other request might have modified some property.

JavaScript 2.0 should interface with other languages even better than JavaScript 1.5 does. If the goal of integration is achieved, the user of an abstraction should not have to care much about whether the abstraction is written in JavaScript, Java, or another language. It should also be possible to make JavaScript abstractions that appear native to Java or other language users.

In order to achieve seamless interfacing with other languages, JavaScript should provide equivalents for the fundamental data types of those languages. Details such as syntax do not have to be the same, but the concepts should be there. JavaScript 1.5 lacks support for integers, making it hard to interface with a Java method that expects a long.

JavaScript is appearing in a number of different application domains, many of which are evolving. Rather than support all of these domains in the core JavaScript, JavaScript 2.0 should provide flexible facilities that allow these application domains to define their own, evolving standards that are convenient to use without requiring continuous changes to the core of JavaScript. JavaScript 2.0 addresses this goal by letting user programs define facilities such as getters, setters, and alternative definitions of operators — facilities that could only be done by the core of the language in JavaScript 1.5.

Waldemar Horwat Last modified Tuesday, October 9, 2001