This post is the second of a two part series on the rise of Javascript as a force to be reckoned with in the world of programming languages. You can read part 1 by clicking here.

In part 1, we had looked at the history, rebirth and the beginnings of the rise of Javascript as the preferred client-side scripting language of the browsers. In this part, we hope to cover the explosion of Javascript since then onto the server, desktop and mobile programming landscape.

Conquering the Server

Continuing on from the browser space, the next piece of the JavaScript puzzle began to be unfurled a couple of years ago with a young hacker named Ryan Dahl. He figured server applications were doing I/O all wrong, and that in today’s multi-core, highly-concurrent world this was never going to scale.

Mostly we do something like this:

context = "today"; // a local variable
data = file.read(); // synchronously read data
process(data, context); // and process it

where the thread doing the read blocks until data has been read from the filesystem and loaded into a buffer. To give some idea of scale, memory is tens or hundreds of times slower than CPU cache (measured in orders of ηs), socket I/O is thousands of times slower than memory I/O (orders of μs), and file and network I/O is thousands of times slower than socket I/O (orders of ms). That means your thread could be doing literally millions of things instead of clogging up the place waiting for some data to come back.

An asynchronous version might look more like this:

context = "today"; // a local variable
file.read( // ask for some data
function(data) { // callback is invoked some time later,
process(data, context); // still bound to context
}
);

where the read function immediately returns and allows execution to continue, and at some arbitrary point in the future — when the data is available — that anonymous function is called with a reference to the context variable still available, even if it’s gone out of scope or changed its value since the call to file.read.

To server side programmers, this might seem completely alien at first. Major server side languages such as Java, C#, C++, etc. are much immature in their use of bindings and closures. Even Python and Ruby aren’t so great at callbacks. So, most server side programmers are quite happy to spin a new fork or thread and join the slow stuff.

nodejs1
Node.js makes JavaScript possible on servers.

However this model is bread and butter to the typical experienced JavaScript programmer. The entire browser is predicated on a Single Event Loop. Your concurrent modification woes evaporate. Mutable state can be shared, because it will never be concurrently accessed, even for reading (which is why the whole DOM-in-the-browser thing works so well with event handlers). They are also aware that the price of this is to give back the conch as quickly as you can. Otherwise you bring the whole browser grinding to a halt, and no-one wants that.

So, for such evented I/O stuff, what better language to use than one where this is the core paradigm? After looking at Google Chrome’s new V8 JavaScript engine, Ryan asked himself: What would it take to get this engine running on a server, outside of the browser? To be useful it would need access to the filesystem, to sockets and the network, to DNS, to processes, … and that’s probably about it. So he set to work building a server-side environment for V8, and node.js was born.

A couple of years later, node.js has grown into a credible server-side container. As well as the core container, the node.js ecosystem contains a saner-than-most package manager called npm. It uses native evented I/O on Linux and until recently would only run with an emulated I/O layer on Windows. Until Microsoft got involved. Microsoft is actively aiding and sponsoring development of tiny little node.js to try to produce equivalent performance on Windows using its (completely different) native evented I/O libraries.

The current stable branch of node.js is showing bonkers fast performance on both Linux and Windows, and only seems to be getting faster. Google’s V8 team are big fans and are actively considering node.js on the V8 roadmap. This could be because they suddenly received a slew of bug reports and feature requests as the uptake of node.js pushed the V8 engine in new and unexpected ways.

The Mobile and Desktop Space

An increasing number of mobile application developers are looking at JavaScript as a really viable alternative to maintaining cross platform applications in a variety of different languages such as: Java, C++, Objective C, etc. The proliferation of JavaScript engines such as the V8 from Google has allowed innovative solution providers such as Sencha Touch, jQuery Mobile and PhoneGap provide HTML5 interfaces for creating mobile applications that can be cross-compiled to different platforms providing a cross-platform application development tool for mobiles.

Also HTML5 and related new technologies are allowing web developers to cater to different mobile devices using javascript to switch between a standard desktop version and a mobile optimized version for those people using mobile platforms. This allows the developer to reuse code from the main site and avoids the hassle of maintaining a completely different version of the application/website for mobile platforms.

JavaScript - Platform Agnostic
JavaScript – Platform Agnostic

But something that caught the entire industry by surprise was the ascent of JavaScript onto the desktop space. At least two major desktop providers (probably the two leading desktop platforms): Gnome and Windows 8. Microsoft while developing it’s new Windows 8 platform had expressed their desire to make the HTML5 stack a viable alternative to developing applications on their spanking new desktop. Christened WinJs, you can develo standards-based HTML, CSS, and JavaScript for the windows platform without worrying about cross-browser issues.

Recently, the developers of the new Gnome 3 desktop environment, promoted JavaScript as a new “first-class” language and will actively promote the development of applications for the Gnome desktop using their JavaScript engine: Gjs based on Mozilla’s SpiderMonkey engine. Among other things, the Gnome developers chose javascript for the reasons stated below:

  • Our language of choice needs to be dynamic and high level.
  • There is already momentum in the GNOME Project for JavaScript — it’s used in GNOME Shell and GNOME Documents.
  • There’s a lot of work going into the language to make it especially fast, embeddable, and framework-agnostic.
  • JavaScript is increasingly being seen as a first class desktop programming language — it us being used in Windows 8, mobile platforms, and for local web applications.
  • JavaScript is self-contained — it doesn’t come with its own set of core libraries, which makes it more convenient for us when integrating it into the platform.

JavaScript Everywhere

And it doesn’t stop there. JavaScript’s serialization form, JSON, is becoming ubiquitous as a lighter-weight alternative to XML for streaming structured data, and NoSQL databases like mongo are happily using JSON and JavaScript in the database as a query language. This means, for the first time, you can have the same JavaScript function in the browser, on the server and in the database.

Tablets such as the sadly-but-hopefully-not-forever-demised HP TouchPad and the nascent Google ChromeOS tablets are using JavaScript (and node.js!) as a core technology. Instead of targeting a closed platform like iOS you can simply write a web app — possibly taking advantage of other tablet-specific APIs or event sources such as a GPS or accelerometer — and it will Just Work on your tablet device. Sadly the most open technology is available on the smallest proportion of devices, and vice versa, but you can still reach a lot of people just by writing a slick web application.

One interesting tangent is that a number of folks are considering JavaScript as a compilation target for other languages. The Clojure language has recently spawned ClojureScript, which is a compiler that emits JavaScript so you can run Clojure in your browser, and a new language called CoffeeScript has emerged. It aligns very closely with JavaScript — you can see exactly how your CoffeeScript expressions turn into the equivalent JavaScript — but lets you get away with less syntax.

Conclusion

This concludes our 2-part series on the emergence of JavaScript as a very powerful language in today’s software landscape. Most of the core language problems have been solved by now and JavaScript just keeps exploding onto newer platforms. A recent phenomenon is the emergence of .js libraries such as backbone.js, underscore.js, kinect.js, etc. and even php.js that provide enhanced library-like functionality to the core JavaScript. It is very hard to beat JavaScript  in terms of being able to deliver full-stack applications, as by the combination of HTML 5 and server-side JavaScript. It’s an exciting time to be developing for the browser — and the web, mobile and server — and it’s never been easier.

The Rise and Rise of Javascript – The Omnipresent Programming Language – Part 2

One thought on “The Rise and Rise of Javascript – The Omnipresent Programming Language – Part 2

Your Thoughts: