Why JavaScript Won

2023-01-31

In this essay, we will explore the history of JavaScript and examine the factors that have contributed to its remarkable rise to dominance. What drives its continued success and why is it, even in 2022, a must-know language for developers?

Programming JavaScript

Introduction
Origin
AJAX
V8
Going Full-stack
The Framework Wars
Conclusion
Resources

Introduction

JavaScript has come a long way since its inception as a simple scripting language for browsers. Today, it stands as one of the most widely used programming languages, with a strong presence in web development, servers, desktops, and mobile applications. In this essay, we will explore the history of JavaScript and examine the factors that have contributed to its remarkable rise to dominance. What drives its continued success and why is it, even in 2022, a must-know language for developers?

Origin

The early web was limited, with browsers only able to request and display static HTML pages as sent from the servers. To make the web more dynamic, developers sought ways to add interactivity and update the page after it had been loaded. When the management at Netscape decided to add a scripting language to their browser, some of their expectations were for it to:

Allow Document Object Model (DOM) manipulation.
Be very accessible and easy to learn.
Be embedded within HTML files.
Be interpreted.

Created by Brendan Eich for Netscape in 1995, JavaScript (initially LiveScript) is a scripting language designed to add interactivity to the early, static web. For those wondering, JavaScript was named after Java, and the intention was for its syntax to resemble it, too. This happened after the executives at Netscape had explored the idea of embedding Java in the browser. They decided against it, noting that Java would be too complicated to learn. They still adopted the name, which Eich believes was a marketing ploy given Java's popularity at the time.

ECMAScript

Around the same time that JavaScript was released in a new version of Netscape Navigator, Microsoft introduced their Internet Explorer browser. This kick-started the browser wars of the late 90s, resulting in a massive anti-trust case against Microsoft. For their browser to go toe-to-toe with Navigator, Microsoft also reverse-engineered Netscape's JavaScript run time. They released their version of the scripting language and named it JScript. Microsoft's implementation was just different enough to make cross-compatibility poor. As a result, there was a period where many websites had either a ‘best viewed in Netscape’ or ‘best viewed in Internet Explorer’ badge depending on the version of the scripting language in use.

Soon after the release of JScript, Netscape submitted JavaScript to ECMA International, taking the first steps in establishing a universal standard to which fellow browsers could conform. There was some debate about what to call the new standard given that Sun (now Oracle) had a trademark on JavaScript and, eventually, the name ECMAScript (ES for short) was chosen. Three versions of the standard were released between 1996 and 2000. Microsoft did participate in the standards process in the early days and implemented some proposals in their JScript version. However, given IE's dominance (it peaked at a 95% market share), they felt no obligation to contribute to a standard that would only serve to threaten their dominant position. Eventually, Microsoft stopped contributing to ECMA work.

AJAX

Between 1997 and 2001, three developments would be pivotal to the future success of JavaScript. The first was Dynamic HTML which shipped with version 4 of both Netscape Navigator and Internet Explorer. Dynamic HTML allows Document Object Model (DOM) updates to change the content and style of a page after it has already been loaded in the browser. This was followed up two years later by the XMLHttpRequest (XHR) web API that facilitates asynchronous communication with a server, allowing data retrieval without a full-page refresh. The last was the development of JavaScript Object Notation (JSON) by Douglas Crockford in 2001. The idea behind JSON was to store data in a text file using JavaScript syntax. JSON has since surpassed XML in web development because it is lightweight and easier to consume when using JavaScript.

It was these technologies that Jesse James Garrett was referring to when he published the now-iconic whitepaper titled Ajax: A New Approach to Web Applications in 2005. AJAX, or Asynchronous JavaScript and XMLHttpRequest, refers to the use of asynchronicity to build non-blocking web pages that can communicate with the server in the background. The constituent technologies include XHR for asynchronous communication, HTML and CSS for presentation, the DOM to display and make the data interactive, and JSON or XML for data exchange. These technologies allowed developers to populate the DOM with the results from, for example, an external API call without rendering the page unresponsive.

Asynchronous JavaScript is significant because it solves one of the most annoying aspects of early JavaScript. Before asynchronous JavaScript, any long-running task being executed in the background would make the page unresponsive. Such a task could be a file upload or an ongoing HTTP request. The reason is that, with synchronous functions, the caller must wait for it to execute to completion and return a value. Asynchronous functions return immediately and allow the program to remain responsive. The user experience improvements were enormous, especially as we ushered in Web 2.0 and the age of dynamic web apps that rely heavily on remote data processing and storage.

Garrett's whitepaper was published during a resurgence of JavaScript, driven by the release of Mozilla Firefox, the successor to Netscape Navigator. Firefox was well-received by the public and soon began to chip away at IE's market share. Emerging around the same time was also Dojo Toolkit, an early JavaScript library that provided the necessary infrastructure for large-scale JavaScript development. Others like Prototype and the seemingly immortal JQuery soon followed. Despite the lingering perception of JavaScript as a slow programming language, its popularity would continue to rise as these frameworks made it much easier to work with.

V8

The perception of JavaScript as a slow language changed when Google released the Chrome Browser and its built-in V8 engine. This sparked a new browser war, with the focus now on speed. The key innovation in Chrome was using just-in-time (JIT) compilation. JIT compilation or interpretation is a way of executing code that involves compilation at run time (during execution) instead of before. The user code is translated line-by-line as opposed to translating the whole code into machine language, as compiled languages like C++ would. It is ideal for web development because interpreters get up and running faster by skipping the compilation step. However, because interpreters work on the fly, they cannot make the same optimisations to the code that compilers can. There are ways of dealing with this inefficiency, such as using a profiler, but that is beyond the scope of this post.

Going Full-stack

Today, JavaScript is possibly the most popular full-stack language because of Node.js. Created by Ryan Dahl in 2009, Node was not the first instance of JavaScript outside the browser (Netscape Enterprise Server had done it already), but it was still a significant milestone. It is written in C/C++ and combines the V8 engine, an event loop, and I/O APIs to implement a stand-alone JavaScript run time that can handle a large number of concurrent connections with ease. At the time, popular web servers like Apache struggled to handle large numbers of concurrent requests, which became a crucial requirement as the web rapidly grew. Dahl envisioned a world where web developers could use a single programming language for full-stack web applications, leading him to create a server-side JavaScript run-time.

Yet, the advantages of using JavaScript as a server-side language extend beyond just familiarity for developers. The ability to use a single language across the stack makes it easier for lone developers or small teams to build full-featured web applications in less time. Codebases are easier to maintain thanks to the consistency between the client and server sides. Working within the JS ecosystem can also increase developer efficiency as they use the same development tools and libraries across the stack. When using TypeScript, a superset of JS, we can leverage tools like Zod for type safety across the stack to help us write less buggy code.

We have also seen the rise of meta-frameworks like NextJS, Nuxt, and SvelteKit that take advantage of isomorphic JS to build high-performance web apps. Isomorphic JS is a technique that allows pages to be assembled either on the client or the server. Server-side rendering has many advantages, such as faster initial display, better search engine optimisation (SEO), and the ability to run websites on older browsers that may not support JS. It is not a universal solution, however - client-side rendered applications are slower to display initially as they download large JS bundles. They are more responsive once loaded which many users will undoubtedly appreciate.

The Framework Wars

As mentioned earlier, JavaScript frameworks and libraries (for simplicity, I will use these terms interchangeably) began to emerge in the mid-2000s. Today, only 17% of websites use vanilla JavaScript, with the rest relying on some framework. JQuery is one of the oldest and by far the most popular JS library, with the most recent data showing that it appears on over 77% of websites. Created in 2006, JQuery quickly rose to prominence as it made DOM manipulation fun and easy by abstracting over browser differences. Many frameworks have since followed the same formula of providing ready-built, reusable components that vastly improve developer experience (DX). Modern frameworks allow developers to build complex applications using battle-tested building blocks whose kinks have already been ironed out. They provide a solid foundation on which to build modern applications without having to manually implement features that are common across the majority of web apps.

If you pay close attention to the world of web development, you may find yourself lost in a maelstrom of hot new JS frameworks that claim to have fixed web development. In the last decade, Angular, React, and Vue were the hot, innovative kids on the block. Each has its pros and cons and a community of users that will swear by it. Recently, we have seen the emergence of different frameworks offering various solutions to some of the failings of Single-Page Apps (SPAs). A SPA is one where the server sends a single HTML file with a link to a JS file that injects the page contents after running the JS on the client. Some of these solutions include a return to the Multi-Page App Architecture (MPA) with improvements or Progressively Enhanced Single-Page Apps (PESPAs). Next.js, Remix.run, and Astro are three popular, emerging full-stack frameworks that question how much JavaScript we need to ship to the client. Each of these frameworks has a unique way of limiting the amount of JavaScript shipped to the client without sacrificing interactivity. With these tools, we can build web applications that load faster, use less bandwidth, and have better SEO and accessibility. On the other hand, despite its popularity, frameworks like Solid, Svelte, and Qwik have begun to challenge the place that React holds as the de-facto frontend JS solution. What all these frameworks have in common is that they aim to streamline and simplify the developer experience. Each framework addresses specific pain points in its way and they continually evolve by learning from each other.

On the server side, the community has begun to ask serious questions about whether Node should remain the go-to server-side JS run-time. With each release, Node's performance has declined, leaving users with a trade-off between new features and decreased performance. Anyone who builds a sufficiently large Node project will inevitably find themselves in some form of dependency hell, juggling dependencies and resolving conflicts between them. And, despite many people pointing their fingers at Node's package manager (npm), the problem may lie at the root of how the whole ecosystem of dependencies on npm has been constructed. Node has serious security vulnerabilities, with any package you install via npm having full access to do as it pleases on your machine. This is one of the reasons why Node’s creator Ryan Dahl created Deno. Deno offers a level of sandboxing that gives developers control over packages and their execution. It is faster and more secure than Node and supports TypeScript without tools like ts-node. Bun is another Node alternative for the future. It is described as an all-in-one full-stack solution, providing a built-in bundler, transpiler, package manager, and task runner. Although they have not yet achieved the same level of adoption as Node, these projects have potential and are expected to bring excitement to the server-side JavaScript landscape.

JavaScript in Everything

Conclusion

JavaScript has come a long way from its humble beginnings as a client-side scripting language. One look at the state of JS today shows us that, despite the flurry of activity within the community, cracks are beginning to show. On the front end, many innovative frameworks are finding ways to reduce the amount of JavaScript shipped to the browser. Web APIs have vastly improved, offering native support for many functions that used to rely on JS. Node is still dominant, even though many back-end developers are exploring alternatives like Rust and Go to build blazingly fast APIs. To be clear, none of what I have said here is meant to dissuade anyone from learning or using JavaScript - it is still a popular language with a vibrant community committed to improving it. However, there are genuine criticisms of JavaScript as a language and the ecosystems that it has spawned (npm). There are solutions within the ecosystem trying to deal with these issues, but other developers have used this as an opportunity to explore seemingly greener pastures. Ultimately, it is unlikely that JavaScript will fade into obscurity due to its widespread popularity and versatility. The active community will likely continue to develop new tools, enhancing the experience of creating and utilizing JavaScript applications.