JavaScript: A Look Back Before a Look Forward

In a long-term development that still amazes many people--me included--good ol’ JavaScript has become one of the most prevalent and influential programming languages of modern computing. Although it has yet to flirt with the top positions, the language is solidly in the top 10 of the TIOBE Index as of the end of 2014. This index is an indicator of the popularity of the top 100 programming languages. JavaScript has bounced around positions 7 to 12 for almost the last 20 years, an impressive accomplishment for a language that many deride as a toy. It certainly has its warts--more than a few--but nevertheless it is a force on the client side of the Web and increasingly in server applications. Node.js is a big reason for the latter development.

But the world of JavaScript is nearing a rather substantial shakeup, one that you’ll need to pay attention to if JavaScript is at all important to your programming life. JavaScript--really ECMAScript, which is the standardized language, but everyone calls it JavaScript--is nearing the release of version 6. This version is going to be an even bigger release than version 5 was, adding a number of features that will go a long ways toward making it a “real” language. JavaScript just ain’t going to be your mother’s programming language anymore, with support for classes, constants, modules, and a whole lot more.

If you want to dive into the details--and I strongly suggest that you do--check out the still evolving specification for ECMAScript 6 (the official ECMAScript site is www.ecmascript.org). But a better way to explore the new features is at fellow MVP Dan Wahlin’s blog, where he’s just starting up a series of posts about ECMAScript 6, that promises to be a great exploration of just how radical the new version will be. (And while you’re at it sign up for his Web Weekly Newsletter, which isn’t quite weekly, but has some great stuff about emerging Web development technologies.) The lead post in the series has some links to some great JavaScript resources.

In the meantime, as befitting my last column for 2014 (or the first one for 2015, depending on the timing of publication!), I want to take a quick look back at the history of JavaScript. It’s always good to know where we’ve come from. I’m going to be spending some quality time with JavaScript and it’s latest versions in 2015, so will visit this topic often.

A Brief History of JavaScript

Brendan Eich, then of Netscape, designed JavaScript in a mere 10 days from concept to production. The name of the language was originally LiveScript (although some accounts claim the original code name was Mocha, an obvious reference to Java, which at the time was getting a lot of attention). LiveScript shipped with version 2.0 of the Netscape browser in September of 1995, then was renamed JavaScript with the version 2.0B3 release later that same year.

At the time, Sun Microsystems, the owner of Java, wanted to kill LiveScript and make Java the programming language of the Web. The reason that Netscape reportedly changed the name from LiveScript to JavaScript was to capitalize on Java’s growing popularity and to appease Sun. Netscape didn’t want Java to be the language of the browser because the company wanted a simpler programming model to appeal to wider group of programmers who might not be able or willing to learn a complex language like Java.

Around that time, the browser wars between Netscape and Microsoft heated up, and Microsoft reverse engineered the JavaScript engine and called the result JScript because Sun owned the JavaScript name. With support from what was then the two major browser vendors, JavaScript quickly became the programming language of Web clients, and Java slowly disappeared from modern browsers (thank heavens!). Oracle, through its acquisition of Sun in 2010, now owns the JavaScript name, and Mozilla, which rose from the ashes of Netscape, is the official keeper of the JavaScript language.

JavaScript is an interesting language that has both good parts and bad parts. The good parts are a thing of beauty and elegance, the main reason for many people’s claim that JavaScript really is a marvelous language. But the bad parts are sometimes nasty, leading to code that doesn’t quite function the way it seems like it should and often fosters incorrect code.

Where do the bad parts come from? They have three main sources:

For the most part, you can avoid the bad parts. The good parts define a remarkably useful and versatile language, a subset of the whole, and those are the parts that we’ll focus on in this course.

For much of its early years, professional programmers denigrated JavaScript as a deeply flawed toy language, designed as it was (in some ways) to make it easier for amateur programmers, such as Web designers. For a long time, it was far from certain that JavaScript would survive as the programming language of the Web, that some other technology wouldn’t come along and replace it. And for a while it looked like Java might be that technology.

But then an odd thing happened. In the quest for standards-based technologies to make Web pages and applications more powerful, Ajax was born and spawned what Tim O’Reilly of technology book publisher O’Reilly Media called Web 2.0. This vision for the future of the Web contemplates far greater interactivity between users and a site, cooperating together in a dialog as creators of social content in a virtual community. Ajax was the foundation of this new Web, and JavaScript was one of the core technologies of Ajax.

As Ajax grew in popularity and use, professional programmers began taking a harder look at the language and discovered just how powerful and elegant the good parts are, once you get past some of its warts. Then came significant numbers of comprehensive frameworks and libraries that fostered better JavaScript programming practices. This, in turn, caused increased use of JavaScript outside of Web browsers, including on servers. JavaScript finally had earned respect as a first class language worthy of careful study of professional programmers, while remaining approachable by amateurs. For now, the future of JavaScript looks bright and assured.

And with ECMAScript 6, it promises to become a worthy programming language. But will that instead lead to its demise? Stay tuned!