The fifth decade of programming: J is also for JavaScript

Part Two of Chapter Five in a very personal history of programming. Read Part 1 Here.

No, the other left

In my last article, I probably alienated and angered a few million devout worshipers at the altar of Java. This week, I might as well go on and outrage another few million fanatics who love JavaScript more than life itself.

Netscape undoubtedly played a big part in Java’s success, however at the same time it was adopting Java, Netscape was simultaneously developing its own competing language which would one day threaten Java’s dominance. It was originally developed under the name LiveScript but then the marketers rather confusingly chose to get a license from Sun so they could name the language JavaScript.

This is confusing because although in theory JavaScript has a similar heritage to Java (it is an ALGOL descendant via C, SmallTalk, and Self, along with flavors of, Scheme¹), in practice the two share little besides a name. I will not get into the boring technical details. Suffice it to say that to a programmer: JavaScript has almost nothing in common with Java.

While Java was being increasingly used to write “server-side” code and “applets” that the browser would download and then launch as separate applications running in a sandbox², Java­Script slowly but surely became indispensable by virtue of the fact that it was the only language that ran inside the browser. Programmers could use JavaScript to write code that altered an HTML page while it was running.

At first this was used to do things like validation: ensuring that data was entered in a proper format, for example to make sure that people did not enter letters into a numeric field³. However, it eventually became much more important. In 2005 Jesse James Garrett published Ajax: A New Approach to Web Applications, which gave programmers a recipe to make applet downloads obsolete.

Ajax stands for: Asynchronous JavaScript and XML, and the basic technique had been in use for a few years before Garrett’s paper made it popular. It uses JavaScript to change a web page dynamically without re-loading the HTML.

In the third article of this series, I explain:

“When you interact with a web page you are dealing with at least a dozen layers of abstraction. The “button” you click on is really a region of the screen which is caught by the operating system, passed to the web browser, which compares it to a map in memory which was rendered from a “Document Object Model” which was constructed by interpreting HTML (and CSS and JavaScript)”

The way Ajax works is by modifying the Document Object Model (DOM) in memory which causes the pixel rendering to change on screen without reloading the entire page.

The DOM specification has “hooks” to both Java and JavaScript, yet because JavaScript ran inside the browser, JavaScript had a marked advantage, and the Ajax pattern became almost universally used as the technique for creating dynamic web pages. Within a year several “framework” implementations of AJAX were published, the one whose name you might have heard (if you work in IT) is jQuery.

This was the genesis of JavaScript’s popularity. Since then, lots of public domain software written in JavaScript has become available. As with Java, and Objective-C before it: a rich class library of pre-written application components seems to be the key to success for a programming language.

In spite of its tremendous popularity, in my opinion there is nothing revolutionary about JavaScript either. To my eyes it is simply Yet Another SmallTalk clone with features added (admittedly some pretty weird ones) that make it all too easy to program poorly.

In the early millennium, companies like Salesforce.com were proving to IT departments that it was not only possible to deliver applications over the web, but users liked them better than the thick applications that had to be installed via floppy disk or CD. As IT departments adopted this technology, two camps formed: the “dev teams” that wrote in Java, and the “front-end” teams (or web integrators) that wrote in HTML, CSS, and JavaScript.

Netscape had developed a server-side Java–Script implementation called LiveWire Pro Web but it never achieved the popularity of Java. But, in 2009 Ryan Dahl created a new server-side JavaScript implementation named Node.js.

Since Node.js became available, many companies with a Silicon Valley or startup culture have been using JavaScript for both the front-end and the back-end (server-side). These companies, and the programmers that work for them, have a very different culture from the IT departments of large public corporations in traditional sectors.

In most companies, the two camps are very far apart in terms of culture, skills, and often even reporting structure, with Java back-end developer teams reporting to IT, and the Front-end teams often reporting to Marketing.

Nonetheless, server-side JavaScript using Node.js is gaining a foothold in enterprise IT, and publicly available source code (for cutting and pasting purposes) is increasingly JavaScript code.

Whether or not this is enough to displace the installed code base of Java remains to be seen. Either way, I predict that it will make little difference. Languages come in and out of fashion with each generation of programmers. The problem of enterprise IT project failure stems from the fundamental unscalability of artisanal production, not from choice of languages.

“There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.”

~ Lawrence Flon

<- Previous article in the series

[1] A marvelous language the details of which this footnote is too small to contain.

[2] a digital security area outside of the browser.

[3] this is somewhat ironic considering JavaScript’s rather lenient approach to data types.

This article is an excerpt from my upcoming book The Chaos Factory which explains why most companies and government can’t write software that “just works”, and how it can be fixed.