In 2020, the World Wide Web is ubiquitous with over a billion websites accessible from billions of web connected devices. Each of those devices runs a web browser or similar programs that are able to display or otherwise process the web pages that those websites make available. The majority of those webpages embed source code written in a programming language that has been given several names but is usually called JavaScript. In 2020, JavaScript is arguably the world’s most broadly deployed programming language.

In 1995, the web and web browser were new technologies that were bursting onto the word at “internet speed” and Netscape Communications Corporation was the leader in web browser development. JavaScript was initially designed and implemented in May 1995 at Netscape by Brendan Eich, one of the authors of this paper. It was intended to be a simple, easy to use, dynamic scripting language that enabled snippets of code to be included in the definitions of web pages. The code snippets were interpreted by a browser as it rendered the page enabling the page to dynamically customize its presentation and respond to user interactions.

The first part of this paper examines in detail the motivations and trade-offs that went into the development of the first versions of the JavaScript language at Netscape. We explore the early features of the language and the design decisions that motivated them. We also trace the early evolution of the language through its first few years at Netscape. Because of its name, JavaScript is often confused by the uninformed with the Java programming language. We explain the process of naming the language, the envisioned relationship between the two languages, and what happened instead.

One of the reasons for the success of the web is that it is based upon non-proprietary open technologies. Anybody should be able to create a webpage that can be hosted by a variety of web servers from different vendors and accessed by a variety of browsers. But that degree of interoperability among independent implementations requires a common specification that all implementations must support. From its earliest days it was understood that JavaScript on the web would need some form of standard specification and within a year interoperability issues were already arising between Netscape’s JavaScript implementation and Microsoft’s reverse engineered implementation. In 1996, the standardization process for JavaScript was begun under the auspices of the Ecma International standards organization. The first official standard specification for the language was issued in 1997 under the name ECMAScript. Two additional revised and enhanced editions, largely based upon Netscape’s evolution of the language, were issued by the end of 1999. The second part of this paper examines how this standardization effort was initiated, how the specifications were created, who contributed to the effort, and how decisions were made.

By the year 2000,JavaScript was widely used on the web but Netscape was in rapid decline and Eich had moved on to other projects. Who would lead the evolution of JavaScript into the future? In the absence of either a corporate or individual “Benevolent Dictator for Life”, the responsibility for evolving JavaScript fell, by default, upon the ECMAScript standards committee. This transfer of design responsibility did not go smoothly. There was a decade long period of false starts and misdirected efforts as the standards committee tried to envision and design its own path toward an improved version of the language while struggling with finding an effective process for accomplishing that goal. All the while, actual usage of JavaScript continued to rapidly grow creating a huge legacy of unmaintained JavaScript-dependent webpages and revealing new interoperability issues. Web developers were now creating complex client-side JavaScript web applications and asking for language enhancements to support them. But after significant internal turmoil the standards committee successfully reinvented itself and began to make progress on evolving the language and publishing updated versions of the specifications. The third major part of this paper examines the unsuccessful attempts to revise the language, the changes and new features that were envisioned, and the reasons for failure. We explore how the standards committee was restored to harmonious functionality and the technical details of the modestly enhanced edition of the standard that was published in 2009. Both authors of this paper were significant contributors to that and subsequent work of the ECMAScript standards committee.

In 2010 the standards committee was finally ready to successfully undertake the task of compatibly modernizing the language to support new styles of web development. Over the course of five years the committee developed a major enhancement to the language and its standard specification. The result, known as ECMAScript 2015, is the foundation for ongoing evolution of the language. After completion of the 2015 release, the committee again modified its processes to enable faster incremental releases and now regularly completes revisions on a yearly schedule. The paper explores the goals, requirements, and roadmap for the ECMAScript 2015 effort as well as the major new features and technical design challenges the committee faced.

Over the last ten years, the ECMAScript standards committee has grown from a small group of language experts to a large group with more than fifty people attending each of its meetings. The attendees have a broad range of interests and technical skills and the majority have no previous experience with language design or standardization. Yet its work is under constant scrutiny of a massive community of interest. The paper concludes by discussing the current yearly release processes and the committee’s challenges going forwarding

JavaScript was created in the early days of the web era. As such, it is one of the first major programming languages with an extensive digital record of its standardization process. In addition to its authors’ personal experiences, this paper makes extensive use of those documents.