I'm going to add an update to this because I think JS's emergence on the client-side web has been misunderstood on a few key points over the years.
It wasn't Ajax
I'm not saying Ajax wasn't important to the evolution of understanding of JS as a language but the fight for client-side browser dominance was over long before the term Ajax was coined.
It wasn't because it was the only game in town
There were Java Applets, Flash, and VBScript. I've heard there were even other scripting options in the '90s (but required plug-ins IIRC). Java is hugely popular yet applets were a dismal failure. They were ugly and often security-swiss-cheese but more importantly I don't think Java was a good fit for reasons I'll go into later. Flash was very popular and had a strong foothold for a number of years but even when Flash finally had SEO options, they weren't typically used, making exclusively Flash sites very hard to discover. Even now, most of us regularly update Flash so we can see movies but that's the real Achilles heel. Proprietary technology in browsers is annoying. And of course VB, which would only ever work with IE, so no.
Right Place at the Right Time is Relevant But Not the Whole Answer
Yes, without the web wave to ride we may never have seen JavaScript or a language in popular usage like it as soon as we did. Or maybe we would have...
It Ended Up Being the Perfect Tool for the Problem Domain
I'd say around 2000ish we had the following problems:
- IE and Netscape had only just agreed to start playing nice by attending to the same DOM API and CSS standards and we've had to deal with a crap-ton of legacy JS cross-browser issues ever since which are only just starting to become manageable without the aid of JS DOM normalization tools like jQuery post IE8
- There was a whole new generation of web developers/designers who weren't all necessarily heavyweights as programmers looking to improve their game post-.com-bubble-burst when they stopped handing you a decent salary for showing up at the door with nothing more than basic HTML-literacy and some photoshop skills.
- There was this new CSS kid in town that offered intriguing possibilities for what would ultimately be called DHTML, (more appropriately) DOM Scripting, (now inappropriately) HTML5 (zomghtml5!).
So we needed a language that was both deep, offering the ability to actually structure and architect a more advanced app with portable/re-usable components on the client-side but also accessible to people who didn't know a lot and just needed things to appear/reappear when you clicked a button.
Furthermore, MS being the ungainly/incompetent and/or dominance-through-anti-competitive-practice-scheming beast that they sometimes are, failed to really touch their non-compliant DOM API implementation for a good solid decade, although they did manage to add the occasional thing like the original XHR object and querySelectors in IE8.
The important thing to note is that by around 2005 we had managed to so completely bury the complexity involved in handling cross-browser issues that it wasn't really a serious issue anymore on the JavaScript front. The failure to support CSS2 properly for as long as they did caused considerably more pain. For an idea of the sheer volume and depth of issues, I recommend checking out quirksmode.org. I do not think that this is a feat that could have been achieved as smoothly and in as many libraries in Java, certainly not in VB and definitely not with any plug-in strategy whose goal is to sidestep the entire issue by becoming an entirely new kind of nuisance.
Other Language Features That Make a Lot of Sense for UI:
First Class Functions: In my experience, nothing lends itself better to async processing and event-driven paradigms than a language that makes its functions first-class. Both concerns are regularly addressed in UI work.
Dynamic Types: Casting and type-checking is a very rare need in JavaScript which helped keep code concise and lean. UI concerns can get complex and messy very quickly. Keeping code tight and being absolutely clear about flow of data is critical to understanding and modifying/maintaining it.
It's Not Protectionist: For many years somebody's been preaching that you need to protect yourself from your own mistakes and the dumb things the other guy might do with your code by making code constructs highly rigid and inflexible and impossible to meddle with the original intent it was authored with and a lot of people have been listening. I won't say they're always wrong (might think it) but I will say it's the wrong approach to web UI and I do believe that it's something of a phenomenon that we've been cranking out, maintaining, and modifying client-side GUIs at a much faster pace and with greater ease than such work was typically accomplished in more restrictive languages in the past. Being able to change things on the fly quickly and easily makes it much easier to have dynamic/fluid architecture schemes that don't require monumental amounts of indirection and abstraction overhead which ultimately makes it easier to see what the Hell is going on in your code and pre-empt or handle exceptions much more cleanly. It is easier to maintain simply through sheer virtue of making it possible to be more direct in everything you do and with much less code than it would take given the other philosophy.
How did JS become popular? It has proven itself to be an excellent tool for the job time and time again. It is not the language we are "stuck with" It's the language that may have inspired a great deal of evolution in popular languages in general. And for that, you can thank Brendan Eich and any contemporaries who helped put the idea into his head, for liking Scheme as a design-inspiration fit for the problem at hand more than he liked Java.
