Photo by Pankaj Patel on Unsplash

It’s 2019, and the vast majority of new websites tend to be built with JavaScript. They often require JavaScript to run in the end-user’s web browser in order to function. Should you disable JavaScript in your browser (which you can do, but in this day and age you need to be truly masochistic to even attempt this), most websites won’t work at all.

It’s not just the true applications of the web such as Gmail, Google Docs, etc., that require JavaScript to function. Even many of the simple content based websites such as news websites, company marketing websites, blogs, etc., require JavaScript just to display content to you. But websites were not always created this way.

Why did JavaScript become so ubiquitous? Are browser scripting languages needed to make the web work? Why did JavaScript surpass other scripting languages? Why is a single scripting language essential to the entire web? Why are web browsers not able to support more than one language today? And finally, what might the browser of the future look like? I hope to answer all of these questions, but first let’s travel back in time to the beginning of the web by having a quick look at where it all started, so that we can understand how we got to where we are today.

A brief history of scripting on the web

1991 — The first web 🚼

In 1991, Tim Berners-Lee invented the World Wide Web (WWW), known commonly today as the web, to allow physicists around the world to share data with one another. The overall architecture of the first system was client-server based. Tim Berners-Lee created the first HyperText Transfer Protocol (HTTP), the HyperText Markup Language (HTML), the first web browser (called WorldWideWeb), and the first web server software (later called CERN httpd). He married all of these things together to create the first ever website which you can find online today. The conceptual architecture of the solution was client-server based, and it looked more or less as follows:

Architecture of the first version of the World Wide Web

Mr. Berners-Lee’s WorldWideWeb browser didn’t include support for any type of client side scripting, but it was in fact quite feature filled. The browser was discontinued in 1994.

Side note — client-server architectures

Client-server architectures have been around since at least the 1960’s and are still very common today. In a client-server architecture, the client often runs on a machine that is different from the server, and between them, they share the load of a distributed computer program. In Berners-Lee’s initial architecture, with the Web Browser as the client and the Web Server as the server, the server was responsible for the centralized storage of information, and would share this information with clients. At a high level, the browser was built to make a request to the server, wait for a response, and once a server response was received, it would display the server’s response. The server’s responsibility would be to continually wait for client browser requests. Once received, the server would do all of the heavy lifting needed to prepare and return a response back to the web browser.

I like to compare client-server architectures to a restaurant. You as the restaurant patron are the client. The restaurant is the server. The restaurant is a self-functioning unit. It doesn’t need you the patron to operate it. However, it does need you the patron to support it in order to ensure its success. In this sense, most client-server architectures are similar. Clients are not needed for the proper operation of the server, but the server needs the clients in order to complete the product.

Mr. Berners-Lee’s client-server architecture had the web browser act as a “dumb terminal”. The web browser didn’t have the ability to run arbitrary program code, but it had the ability to request data from a server, and present this data in a meaningful way to end-users. The design was fairly static in the sense that end-users could read content and request new content to read, but dynamic programs couldn’t run on web pages, and users couldn’t interact with web pages other than to choose new web pages to read.

1991/1992 — VoilaWWW, the first browser that could execute scripts

The beauty of Mr. Berners-Lee’s HyperText Markup Language was that it could easily be extended to support passing program code to a web browser. The only requirement would be that the web browser would need to have the ability developed that would allow it to read and execute the program code.

So in 1991/1992, the VoilaWWW browser was created as the first browser to have the ability to run a scripting language. The VoilaWWW web browser could run simple programs on an end-user’s computer, such as an auto-updating clock that would update the time in the end-user’s web browser.

ViolaWWW Browser circa 1993 (from https://www.viola.org/)

VoilaWWW scripts ran within the confines of the VoilaWWW web browser. VoilaWWW recognized that there needed to be an ability to run programs safely within the browser to enhance the end-user’s experience, without allowing these programs to have access to files or other programs on an end-user’s computer.

1995—Netscape Navigator 2.0 releases JavaScript

In 1995, Netscape Communications employed Brendan Eich to embed the Scheme language into Netscape Navigator. In December 1995, Netscape Navigator 2.0 beta 3 was launched with support to run JavaScript. The name JavaScript was created mainly for marketing purposes. Java was a growing, popular programming language, so Netscape Communication capitalized on this by naming their scripting language JavaScript.

The ability to run a scripting language within a web browser was nothing new at this point, but with JavaScript, Netscape significantly improved the user experience of writing code within a browser. The code was easier to read, write, and maintain, and the barrier to entry was incredibly low, since it was incredibly easy to include JavaScript code in a website by simply copying and pasting JavaScript code into a web page’s HTML file.This made the barrier to entry so low that anyone, even those that were not technical, could enhance their websites with the use of JavaScript.

Comparison of JavaScript versus Voila script. JavaScript improved usability of writing browser scripts

Side note — server-side JavaScript

Also in 1995, Netscape introduced Netscape Enterprise Server, which was a web server that had the ability to run JavaScript. In 1996, Microsoft added the ability to run their own version of JavaScript (called JScript) on Internet Information Services (IIS), which was and is still Microsoft’s web server software.

Today, Node.js also provides the ability to run JavaScript outside of the web browser, but it wasn’t the first! It has by far become the most popular though. It is used to create administration scripts, RESTful APIs, static websites, streaming services, etc. Node.js development has truly legitimized “enterprise grade” JavaScript within much of the development community, and there are numerous large organizations that have adopted the use of Node.js for their server-side development.

1996-Microsoft Internet Explorer 3 releases VBScript and JScript

In 1996 Microsoft released Internet Explorer 3 (IE3). It included support for not one but two scripting languages! One was VBScript, which was a scripting language that Microsoft had already developed for other uses. The other language that IE3 supported was JScript.

JScript was Microsoft’s version of JavaScript. Microsoft created JScript by reverse engineering Netscape’s JavaScript, and then called it JScript in order to avoid trademark issues of the JavaScript name at the time with Sun Microsystems.

Microsoft’s VBScript was available as an administrator scripting language, but it was also used extensively throughout the Microsoft Office product family, and it was extensively used by Microsoft’s classic Active Server Pages (ASP), a language that allowed developers to create dynamic web pages, similar to JSP, PHP, etc.

It was possible to include either or both VBScript and JScript on the same web page. However, developers that used VBScript in their web pages were marrying their websites to Internet Explorer, since VBScript was a language proprietary to Microsoft. VBScript was even supported all the way to IE11, although Microsoft would have preferred that to not be the case.

Believe it or not, VBScript was even supported all the way to IE11, although Microsoft would have preferred that to not be the case.

The strategy of bringing VBScript to IE3 was likely a strategic decision banking on VBScript developers adopting VBScript in the browser as well, which they didn’t. Thus JavaScript was still the dominant browser scripting language at this point.

The mid 1990’s and beyond — Flash

Adobe Flash started out as a multimedia platform that could run on web pages with the “Flash player”. It was really the only way to support rich media on the internet — video, audio, games.

In 2005 YouTube launched its first website, and the video player at the time was actually Flash based. That same year, Adobe purchased Flash from Macromedia. Adobe eventually evolved the Flash ecosystem into much more than a multi-media platform. It eventually became a very capable platform that could be used to develop general “desktop-like” applications that could run across multiple operating systems, by simply making the Flash files available on a web page.

Adobe Flash always remained a product versus an open standard such as the W3C. For application development and responsive design, it competed with native HTML, CSS, and JavaScript. The writing was on the wall in a way where it simply couldn’t compete with JavaScript’s ability to run without user permission, and JavaScript’s ability to access and manipulate the elements of an HTML document, and really JavaScript’s ability as a more robust language. As such, it was always going to be an uphill battle for Adobe to compete with HTML, CSS, and JavaScript in the general application development space, and as the web has evolved, it has lost almost all of its ground, even in the multi-media space.

Flash itself was part scripting language (ActionScript), but the language never really caught on or influenced JavaScript in any real way. In fact, the ActionScript language modelled itself after the syntax of JavaScript in many ways. This was likely a strategic decision to bridge the gap between JavaScript and ActionScript developers and reduce the risk of declining market share.

2015-Google Chrome and Dart

We’ve moved forward several years simply because all browsers have decided to make JavaScript the lingua franca of web scripting languages. It has evolved into a highly capable language.

In 2011 Google had created the Dart language. The Dart language is a general purpose language that is object-oriented and statically typed. The language was open sourced, so that it’s free to develop with. It is also standardized, similar to ECMAScript, which is the specification for JavaScript. Dart was also more friendly to traditional developers that work with statically compiled, strongly type languages such as Java, C, C++, etc.

Google’s long term hope was to bring support for the Dart language into Google Chrome, since Dart checked off all the boxes necessary to set it up for success. Google Chrome would have included a Dart Virtual Machine (VM), which would have been the sandboxed runtime used to run compiled Dart code. This move would have likely improved the runtime performance of scripting within the browser since there would be more potential for greater runtime optimization of code due to static typing etc.

But in 2015, Google decided to cancel integration of the Dart language into Chrome. Google decided that it wasn’t in the best interest of the web in general. Dart support within Chrome would have likely been an uphill battle for Google to support, since the JavaScript development ecosystem was rapidly evolving and improving, and JavaScript by this time was simply too ubiquitous.

In order to keep support for the Dart language going, Google decided to create a transpiler for Dart that would instead convert Dart source code into JavaScript code, which could then run within web browsers. But, Dart adoption never really took off outside of Google.