The JavaScript community is reaching a point where many developers are now younger than the language they use every day. The years of the first browser war and JavaScript’s path to industry domination are topics that are now only known to the most senior programmers. But how much does this history actually matter?
The JavaScript of today is much different from its initial release, and learning the details of its transformation helps us as developers, designers, project managers, and all web users better understand its nature and future potential.
For example, Brendan Eich regretted adding the loose comparison (==) operator instead of sticking solely to a strict comparison (===) in JavaScript 1.0. There’s also the general weirdness of null having a type of object, or NaN having a type of number, and JavaScripts prevailing struggles with security vulnerabilities. By reading up on our history, we can learn what lead to these behaviors. Afterall, a language famous for being created in 10 days is bound to have imperfections.
JavaScript has grown overtime to be more than a scripting language, to the extent that disabling JavaScript in your browser makes the web almost unusable. How did JavaScript become such a necessity for the modern web?
We’re going to start this story in 1993, around the time when the first web browsers were being released. JavaScript’s mother company, Netscape, initially created by members of The National Center for Supercomputing Applications (NCSA), was a group at the University of Illinois that developed the first web browser, Mosaic, in 1993. The following year, Marc Andreessen and Eric Bina, along with several other former colleagues, left the NCSA to create Netscape.
The NCSA Mosaic web browser played a huge role in making the web more user friendly. The “Mosaic” name itself actually referred to its ability to handle various internet protocols such as NNTP, Gopher, FTP, and HTTP.
A year after the NCSA Mosaic launch, Netscape launched its own web browser which was considered more advanced and more usable. Within the first four months of its release, it had already taken three-quarters of the browser market.
The next release was Netscape Navigator which was wildly popular and introduced millions of people to the world wide web for the first time. The company advertised that "the web is for everyone" and stated one of its goals was to "level the playing field" among operating systems by providing a consistent web browsing experience for all of them. It was during this time period when JavaScript was created.
In late 1995, Microsoft was starting to catch on to the competitive threat the web posed. So the team at Microsoft started the Internet Explorer (IE) project in an attempt to take control of the emerging technology from Netscape through an “embrace, extend, extinguish” strategy. Microsoft was now a threat to Netscape.
In response, Netscape decided to target a larger audience by incorporating a scripting language which would allow interactions with the DOM. To achieve this, they collaborated with Sun Microsystems to embed the newly created Java programming language, and hired Brendan Eich to embed the Scheme language.
Many developers are aware that Java and JavaScript have very little in common, but their early history is surprisingly intertwined. In 1992, James Gosling had begun work on a language that would become a successor of C++. After failing to incorporate his new language into interactive television, Gosling renamed it from “Oak” to “Java,” and worked with Sun Microsystems on an aggressive marketing campaign. After realizing that Sun and Netscape had a common enemy in Microsoft, the two companies decided to negotiate a deal where Java would be integrated into Netscape 2.
In comparison to Microsoft, who had Visual C++ for professional programmers and a Visual Basic scripting language for amateurs, Netscape wanted a simpler companion script to Java that mimicked what Microsoft was offering.
This is where Brendan Eich, father of JavaScript, comes into the picture. Eich was hired by Netscape in April of 1995 with the promise of implementing a scripting language for the browserWith the Java announcement now imminent, Eich was given a mere 10 days to produce a prototype.
“I’m to blame for JavaScript…it was supposed to be a sidekick language to Sun’s Java language, but times have changed…and JavaScript had enough good in it that the sidekick became the superhero,” - Brendan Eich, TEDxVienna
The initial version Eich created was called Mocha. It was important to both Netscape and Sun that Mocha “looked like Java.” To accommodate this, Eich used syntax influenced by C, and implemented naming conventions that are similar to those found in Java. Eich also applied the prototype-based object model from the Self language, meaning Mocha would have objects that inherit directly from other objects.
Unfortunately, Eich was unable to fulfill his original goal of implementing Scheme in Mocha. However, he was influenced by it to add Lisp-like first-class functions. This essentially treated functions as variables. So in the end, Mocha had the syntax of Java, the object-orientation of Self, and the functional style of Scheme.
Mocha was later renamed JavaScript, which was a marketing gimmick that presented this new language as a scripting language for small client-side tasks in the browser, while Java would be promoted as a bigger, professional tool for more complex web components. The name similarity and its implication that the languages are closely related has been a continuing source of confusion, even today.
JavaScript was far from loved at first. Experienced Java developers felt the language was too simple and beneath them, while designers and authors struggled to use it. However, it provided content creators with “UI glue” which made a huge difference in user experience, and competing browsers realized that they needed to come up with their own solution, which eventually led to the first browser war.
Microsoft responded to Netscape’s JavaScript with its own reversed engineered version. This copy was named JScript, and was supported in Internet Explorer 3.0, released in August of 1996. Differences between JScript and JavaScript were minimal, since their syntaxes were essentially the same. However, the original JScript was an ActiveX Scripting engine, which allowed it to access objects within IE. In contrast, JavaScript was using an early version of SpiderMonkey and was unable to access any objects within the web browser.
Since Netscape was trying to stay ahead of Microsoft, they decided to set a standard across all web browsers, as they wanted to integrate JavaScript into as many platforms as possible. They approached the European Computer Manufacturers Association (ECMA), a nonprofit standards organization for information and communication systems, in a bid to make JavaScript a web standard before Microsoft could attempt to standardize a Visual Basic based web language or claim their version of JScript as the web standard.
As a result, TC39, an ECMA technical committee focused on creating standard definitions for JavaScript, was formed. At the time, this committee took Netscape’s JavaScript and Microsoft’s JScript to create a standardization called ECMAScript.
ECMAScript 1 (ES1) was released in 1997 with ES2 released in the following year. Not much changed between these two versions. However, in 1999, the release of ES3 added strict equality, regular expressions, switch statements, and try/catch handling. ES3 was the last major update to the ECMAScript specification for almost a decade.
The original plan was that Java would be the primary language for implementing complex web applications and JavaScript would be used within form-based applications. But as experience with JavaScript grew, web developers began to realize that all they really needed was JavaScript.
By the early 2000s, there was still a large amount of misunderstanding and dislike surrounding JavaScript. Even some self-help books published during this period didn’t fully grasp the fundamental elements of the language. Despite this, JavaScript usage was steadily growing. New industry leaders emerged, such as Douglas Crockford, who was the self-proclaimed first person to discover the “good parts” of JavaScript, and is credited with the creation of JSON, JSMin, and JSLint.
“I was the first person to recognize that JavaScript had good parts…and when I announced my results they were met with wild skepticism. No way, there cannot possibly be any good parts in JavaScript.” - Douglas Crockford, Frontend Masters
The first ever JSON message was sent in April of 2001 from a Bay area garage. Crockford, along with his co-founder Chip Morningstar, was trying to build AJAX applications before the term “AJAX” had been coined. A few years later, UX designer Jesse James Garrett published a paper officially defining AJAX as Asynchronous JavaScript and XML calls used by emerging services like Google Maps. This new asynchronous trend improved user experience by eliminating the reloading of the whole page when receiving new data. Despite the “X” in AJAX standing for XML, Garrett later pointed to JSON as an entirely acceptable alternative, boosting JSON’s popularity.
The 2000s was a period of both innovation and conflict. There was the launch of large client-side applications like Gmail and Google Maps; the release of some of the first JavaScript libraries and frameworks including Dojo, JQuery, and MooTools; the first iPhone was sold in 2007 forcing JavaScript to take mobile development into account; and even newly published browsers such as Safari, FireFox, and Chrome had begun to slowly compete with IE. However, there was still much room for improvement due to the tech bubble burst in 2000 and the failure to release new JavaScript standards under ES4.
The first draft of ECMAScript 4 was dated February 1999, and over time many features were proposed, including classes, interfaces, and optional type annotations. ES4 was beginning to look more like our modern-day version of TypeScript. Crockford, who was involved with TC39 during this period, was concerned that the proposal was too complex and bloated. Microsoft agreed, refusing to have any part of the ES4 proposal.
With Internet Explorer still dominating the browser market at 90 percent, Microsoft contributed to ECMA, but mostly played by their own rules, shipping new features for JS for their browser only. This, coupled with Microsoft backing out of ES4 discussions, led to two different proposals running at the same time: ES4 and ES3.1.
This early to mid-2000s era is sometimes referred to as “The Dark Ages,” as it slowly transformed into a renaissance by the end of the decade.
The year 2009 heralded the kickoff of JavaScript’s rebirth, with two major additions that transformed the JS Ecosystem: Node.js & ES5.
The release of ES5 brought developers features that were absolutely necessary, while Node.js transformed JavaScript from a scripting language to a full-fledged programming language by allowing developers to execute scripts outside of the browser.
Node.js was created by Google software engineer Ryan Dahl in 2009, and adopted a variation of the CommonJS specification. The success of Node was partially due to the release of more complex web apps such as YouTube and Facebook, which proved to web developers that top-notch web experiences were possible.
Node also used the new technology of Chrome’s v8 engine, which provided node with the ability to run JavaScript anywhere. Node made it easy for developers to rapidly prototype websites on both the front-end and back-end. This flung the door open for developers to become full-stack, as it no longer requires having to learn other languages such as PHP, Python, or Java.
Once Node reached maturity, people saw the advantages in terms of speed, server costs, and learning costs. This led Node to be used and adopted by many startups, eventually bringing about frameworks such as Electron used for building desktop applications) and Meteor (used for producing cross-platform code).
After the long struggle and ultimate failure of ES4 in 2008, TC39 focused on ES3.1. ES4 was already recognized as a specific variant of ECMAScript with Adobe’s ActionScript for Flash, so the committee decided to rename ES3.1 to ECMAScript 5 to avoid confusion.
ES5 was officially released in December of 2009, and was known as a great “compromise.” The 10 years of disagreement over ES4 was behind them, and this new version added several enhancements to the standard library. ES5 became one of the most supported versions of JavaScript. It was fully supported by Firefox in 2011, followed by Chrome, Safari, and IE in 2012.
None of these changes required major syntax updates, and ES5 was overall a modest improvement that helped JS become more usable. It became fully supported by all browsers in 2014.
While jQuery was the most popular JavaScript library for web interfaces, it lacked facilities for handling data consistently across shared views. Several frameworks and libraries were built to tackle this problem. Knockout, Backbone, and Angular are some of the earliest.
Knockout JS released in July of 2010, and helped connect parts of the UI to a data model using declarative bindings, but lacked a strict application structure that made later frameworks more popular.
In October of the same year, Jeremy Ashkenas released Backbone, the first framework aimed at creating single-page applications. Ashkenas had seen how messy a large JQuery application could become and wanted to create a cleaner approach.
The same month Backbone released, Google engineer Misko Hevery unveiled Angular, which was the first framework that provided a complete architecture for front-end applications. Angular was an all-inclusive framework, compared to Backbone’s lightweight approach, and it quickly became popular.
Around the time single page applications were gaining traction, Ashkenas developed CoffeeScript, a language influenced by Ruby, Python, and Haskell that transpiled to JavaScript.
CoffeeScript was the first language that made transpiling go mainstream. Transpilation is a process for converting one language, like CoffeeScript, to another language, like JavaScript. This empowered developers to grow the language themselves. Most modern frameworks now utilize some form of transpiling, influenced originally by Ashkenas.
“The way you invent the future of JavaScript is to compile the JavaScript of the future into the JavaScript of today.” - Jeremy Ashkenas, CODE GENIUS
By 2015, JavaScript was beginning to look more like the JavaScript of today. Seven years passed between the finished version of ES5 to the release of ES6, nicknamed Harmony, and later renamed officially to ECMA2015.
ES6 was incredibly different from ES5, and has been the largest update to JavaScript to date. This new major version required transpilers, such as Babel or Typescript, in order to be compatible with older browsers. More complex frameworks were also released, like React and Vue, leading to the creation of bundlers like Browserify and webpack, that were needed to help manage dependencies.
The Renaissance period of the early 2010s and the Harmony Release of 2015 were mostly responsible for this plethora of new technologies and constantly evolving trends in the JavaScript community, which continue to be prevalent today.
It became quickly apparent that the plans for ES6 Harmony were too ambitious for a single version, so its features had to be split into two groups. The features considered to have the highest priority were shipped first in ECMA2015. After Harmony’s initial release, TC39 made a decision that ECMAScript would have yearly, smaller releases, in an attempt to avoid the mishap with ES4, and to get out some of the lower-priority features on a more regular basis.
This major update actually included many features originally proposed for ES4, like the addition of classes as syntactic sugar and the addition of a modules system, but left out the more controversial features like optional type annotations.
TC39 has been consistent in adding new, smaller updates to the JavaScript language as promised. This new method is a huge improvement compared to the 10-year hiatus of the 2000s.
Unfortunately, when ES6 was first released, developers struggled to use it due to a lack of support in many legacy browsers. This influenced the creation of transpilers such as Babel or TypeScript that could convert ES6 syntax to any version of JavaScript back to ES3.
In 2016, the core version of Babel was downloaded 5 million times a month. However, as of 2018, all major browsers support ES6 and use of these generic transpilers has greatly decreased.
Popularity for transpilers that offer additional features (or even a completely new language for web development),has remained steady. A couple examples of these transpilers include TypeScript for a language with a JavaScript type system or Elm for a functional language — both of which transpile down to the JavaScript we know and love.
In May of 2013 the React JavaScript framework was introduced. Created by Jordan Walke, a software engineer working for Facebook, the new framework offered features such as the Virtual DOM, the one-way data flow, and the Flux pattern. The following year, ex-Google employee Evan You released Vue, a lightweight alternative to React and Angular.
Use of Angular waned during this time period, as other new frameworks gained popularity. But in 2016, Google developers released Angular 2, which was a substantial shift compared to the initial version. This new Angular required TypeScript, catered to the mobile users, and focused on creating large applications.
Browserify, published in 2011, was the first mainstream JavaScript bundler, initially designed to help Node developers reuse their code in the browser. Essentially Browserify wanted to “browser-ify” your Node code. Before Browserify, if you were writing a JS module that worked in both Node or the browser, you’d have to manually write code checks for the platform it was running on.
By 2014 npm had grown to over 50,000 packages, and developers needed an easy way to reuse those modules within their code. Browserify solved this by making the CommonJS module system and Node built-ins work in the browser by implementing polyfills and building a single bundle file.
Browserify was doing well; however, by 2015, a new bundler, Webpack, had started to pick up steam. Boosted by React’s popularity, Webpack was different from Browserify as its initial goal was to create a dependency graph for all the assets in a website, so not just JavaScript, but CSS, Images, SVGs, and more. This made it easy to define components as standalone modules, which could then be reused or published to npm. Webpack has maintained its popularity, and is still widely used today, with over 17 million weekly downloads on npm.
We can’t discuss the future of JavaScript without first talking about ES.Next. ES.Next is a dynamic name that refers to the next version of JavaScript, so at this time that means ES2022, which will be released next year.
Every feature added to ES.Next must first go through a five--stage process. We can reference proposals in stage three and four to most accurately predict the near future of ECMAScript, since these new features are near completion by stage three, and ready to be included in the standard by stage four. Proposals in stage zero through two are still being reviewed, and there’s no guarantee that they will ever be included in the standard. There are more than 90 proposals still in stage one, and while stage two features have a better chance to reach completion, they are still in a primitive state.
For a long time, web browsers only allowed one programming language, meaning that all front-end developers needed to learn JavaScript, as opposed to back-end developers who work with more languages. In the same way that node made it possible to use JavaScript on the back end, many developers are wondering if they can make a back-end language work in the web browser.
This is where WebAssembly comes in. Specializing in fast, full-fledged calculations, WebAssembly offers developers an alternative language for front-end development. More specifically, it gives programmers the ability to compile back-end languages, such as C++ or Rust, to a low-level assembly language. WebAssembly was fully supported by all major web browsers in 2017 and is slowly becoming a more widely used language, working in tandem with JavaScript.
There are also methodologies, like Jamstack, that have continued to grow in popularity. Jamstack’s mission is to upgrade traditionally large websites and CMS’s that rely heavily on servers, plugins and databases to instead use JavaScript to load data from an API, serving files from a CDN and generate markup using a static site generator. With this method, developers are able to implement better performance and scalability.
We’ve all heard the classic joke that there are more JavaScript frameworks out there than developers actually using them. But there’s an interesting new contender that’s recently gained traction, called Svelte. This framework provides a different approach to building web apps. While frameworks like React and Vue do the bulk of their work in the user's browser while the app is running, Svelte shifts that work into a compile step that happens when you build your app, producing optimized JavaScript.
Machine learning and AI have also been gaining traction in the JavaScript community. From asking Siri to play a song to using navigation apps on your phone, AI sneaks its way into everyday life. In 2018 Google released TensorFlow.js, making it so developers no longer need to know Python. They can now write AI and machine learning applications using JavaScript.
JavaScript is one of most widely used technologies according to a StackOverflow 2021 developer survey, and it’s retained its number-one status for the past nine years. It went from being widely hated upon creation to now dominating the industry — but why?
Most of its more recent success can be attributed to the large community behind it. The community is constantly evolving the JavaScript language and ecosystem, and is sharing millions of npm modules every day.
So we know what the near future of JavaScript is based on ES.Next proposals, current trends, modern frameworks, and an active community. But what about the far future — like, decades from now? It’s obviously difficult to predict that far ahead, but that doesn’t mean we can’t attempt to brainstorm what the future of the web may look like.
Some community members are already starting to talk about possibly implementing native support for machine learning and AI, functional programming influencing the design of the standard, or JavaScript being used as a language specifically for machines.
This is all assuming that JavaScript will not disappear and be replaced by another language, although odds are pretty good it will survive for years to come, since it’s typically easier and more common to build new technology on top of an older one.
Being knowledgeable about JavaScript’s history can help you identify what these future trends will look like, and also help you understand its nature, strengths, and limitations. This makes it easier to recognize how inherited problems still exist and behave a certain way.
The modern web remains incredibly dependent on JavaScript. This widespread adoption is not going away anytime soon and should encourage all web users — whether they know how to program or not — to be aware of what JavaScript is and where it comes from.
Ultimately, caring and being knowledgeable about this history means you support the future of web development, whether that future includes JavaScript is up to us, the community, to decide. Happy coding.
Sign up for our email newsletter. Nothing spammy about it. Just a monthly rundown of what we’re sharing.
