JavaScript isn’t, and never was “the only client-side language”. At most, for a certain period of time, JavaScript was the only programming language with built-in support in all major browsers. Given the popularity of the Web, that made JavaScript very successful.

JavaScript was created back in 1995 by Brendan Eich, who was recruited by Netscape specifically in order to embed a programming language into its eponymous browser. The reason for this was the realization, by Netscape management, that in order to successfully compete with Microsoft, they had to transform the browser from a document displaying tool into an applicative platform.

The original intent was to embed the Scheme programming language, but before Brendan Eich could start, Netscape began a collaboration with Sun to integrate the Java programming language into the browser. However, Java was seen as a “hardcore” programming language intended for “real programmers”. Consequently, Brendan Eich was now tasked with creating a simpler scripting language, which could be used by Web designers to automate browser components, including Java Applets. And it was decided that this simple scripting language should have a syntax similar to Java. Brendan Eich was able to design and implement such a language in ten days - thus JavaScript was born.

As you can see, even in the beginning, JavaScript wasn’t alone, but rather existing side-by-side with Java inside the browser. Moreover, Netscape management instructed Brendan Eich to intentionally limit JavaScript’s capabilities so that it remain simple, and wouldn’t compete directly with Java. For example, he was not allowed to implement classes in JavaScript. But instead of creating a crippled language, Brendan Eich actually did an end-run around these dictates, for example by implementing prototypal Inheritance in JavaScript - an arguably more flexible inheritance mechanism than classes. This is also why JavaScript lacked a module system for a long time.

JavaScript quickly became very popular, especially because Java, while also running inside the browser, had very limited access to the HTML. Instead Java got its own screen real-estate, where it had to render everything itself, like a plugin. And so, when Microsoft introduced Internet Explorer 3.0 (IE3), it included its own JavaScript implementation, called JScript (reverse-engineered from Netscape JavaScript). But, in addition to JScript, Microsoft provided another scripting language inside the browser: VBScript. VBScript was based on Microsoft’s Visual Basic language, and had the same access to the HTML as JScript. So now you actually had three languages running inside browsers.

For a while it even looked like VBScript might beat out JavaScript because:

1. You could use it for both client-side and server-side development, in Microsoft’s then popular ASP
2. Another Visual Basic derivative - VBA - was introduced into Microsoft Office
3. VBScript in IE3 and later IE4 was actually more powerful, initially, than JScript. For example, it had error handling, which JScript didn’t have at that time (no exception handling yet)

But JavaScript had the great advantage that it worked inside both Netscape and IE, while VBScript was only supported in IE. Also, JavaScript’s C/C++/Java style syntax was more attractive to many developers than BASIC-style syntax. Unfortunately, Microsoft and Netscape were locked in a “browser war”, and wouldn’t cooperate on proper standardization for JavaScript and for HTML (DOM). This almost killed the Web, and JavaScript along with it.

Luckily for JavaScript several things happened:

• Due to a lawsuit by Sun in 2001, Microsoft dropped Java support in Windows, effectively killing client-side Java for years to come, including inside the browser
• JavaScript standardization work began in Ecma International, which led Macromedia (later acquired by Adobe) to use it as a basis for their ActionScript language in Flash
• Microsoft itself introduced XMLHttpRequest back in 1999, and the term Ajax was coined in 2005. These made it possible to use JavaScript and the browser DOM to create powerful Single Page Applications (SPAs)
• The ActiveX mechanism, which Microsoft was promoting as a means for browser-side development died due to continuing security concerns, and lack of cross-platform support
• The introduction of mobile devices, starting with the iPhone in 2007, and the end of the Windows client-side monopoly, prompted developers to seek out cross-platform solutions. And JavaScript in the browser was the best option, by far. Steve Jobs famous letter, written in 2010, and titled “Thoughts on Flash” is a major milestone in this regard
• HTML5, CSS3, and ECMAScript 6 transformed the browsers and JavaScript into a powerful platform for front-end development. Especially when coupled with the highly capable development tools built into modern browsers, and with a new generation of front-end frameworks, such as Angular and React

As a result, JavaScript became the popular choice for front-end development. In 2007 this led Jeff Atwood to coin his Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

But while it was the leading option, JavaScript wasn’t the only option. You had languages like CoffeeScript, introduced in 2009, and ClojureScript, introduced in 2011, and others. But debugging these languages in the browser was challenging, and JavaScript was considered to be Good Enough by the vast majority of Web developers.

Then, in 2013, asm.js was introduced as a means for compiling languages such as C/C++ into JavaScript, so that they could run in the browser. And starting in Firefox 22, asm.js optimizations were introduced, so that such code could run at speeds approaching native execution. This ultimately lead to the creation of WebAssmebly (wasm), which is a binary compilation target, supported by all modern browsers. There are still some limitations on WebAssmebly, such as lack of direct DOM access, which require the inclusion of at least a bit of JavaScript code. But frameworks are already appearing, which work around this limitation, such as Yew for Rust.

Also, let’s not forget that even while all this browser-based development was taking place, native client-side programming never went away. Microsoft kept introducing technologies such as .NET, C#, WinForms, WPF, and finally Universal Windows Platform apps. And as Windows client-side development began to wane, mobile native development rose to take its place, as is amply seen in the great success of the Apple Store, and Google Play Store. Modern mobile apps are written in a variety of programming languages, including Objective-C, Swift, C++, and now Kotlin. Even Java has made a comeback on the client-side, especially for Android.

Interestingly, JavaScript has also become popular for native mobile development, thanks to technologies such as PhoneGap and React Native. There are several reasons for this, such as the widespread availability of JavaScript developers, and the fact that in many cases, versions of the same app need to be developed both as native and as browser-based. Being able to reuse at least some of the code is very beneficial.

As you can see, JavaScript is not the only client-side programming language.

Indeed, as I have shown, it never really was.