Once upon a time - okay, about 1996 or so - there was a race for dominance of this new thing called the World Wide Web. On one side was Microsoft, having firmly staked its ground a few years before with the introduction of Windows 3.0. On the other side was a little startup called Netscape that had only one product - a web browser - that it had been beta testing for a couple of years for free but was now faced with trying to get people to actually pay for said browser. So one of the programmers there, a bright guy by the name of Brendan Eich, came up with a novel concept - a simplified scripting language that borrowed some of the syntax from the new Java language that Sun, just down the road in the Bay Area, had debuted a few months earlier, added in a few constructs that were a bit groundbreaking, and made it possible to alter the fields of the new HTML form controls that had just come out.
The first versions were, like much of the web at that time, laughably crude. However, they paved the way for a fairly radical notion - that the document object model of a page could be manipulated. That manipulation was initially very limited, partially because there were few things that JavaScript could act on, and partially because the language itself was rather painfully slow. Saying you were an expert in JavaScript was a good way to not get a job, when the big money was going to C++ and Java developers that were writing real code.
Eighteen years later, things have changed rather radically. Several major innovations have occurred in the JavaScript world, and these have significantly shaken things up.
AJAX and JSON. The ability to communicate between the client and server out of band (out of the initial load from the server) made it possible to turn the web browser into a direct communication portal with a potentially large data store, in effect establishing the notion that the client need not be restricted to a read-only view of the universe. AJAX also made the idea of using serialized JavaScript objects - combinations of atomic primitives, hash maps and arrays - as data transport protocols feasible. In this regard, it may very well have short circuited the SOAP-based services oriented architecture model and usurped XML's role as a data transport language.
jQuery. One of the biggest challenges that any web developer faced since the introduction of JavaScript has been the fact that there have been, at any given time, at least two and in some cases four or five different but similar APIs for working with web browsers, depending upon the vendor of that browser. This made developing applications painful, and kept cross platform applications to a minimum. After AJAX sparked renewed interest in the language, however, one side effects was the emergence of different JavaScript libraries that provided an abstraction layer to the interfaces, so that you could write to the library and not the browser. A number of these floated around for a while, but by 2011 or so jQuery had become the evident leader, and the concept of JavaScript as web "virtual machine" began to inch closer to reality.
Functional JavaScript. The jQuery libraries in turn forced a rapid evolution in both the capabilities of JavaScript, and in the way that JavaScript itself was written. Gone were the days when JavaScript applications looked like Java applications; the language was now far more functionally oriented, asynchronous and built around callbacks. It truly was an event-driven language, and several other declarative languages that had until comparatively recently found more success in academia than in the commercial world - Haskell, Ocaml, Scheme, Miranda - ended up getting pillaged for ideas in taking JavaScript to the next level - with the use of monads, functions as first class objects, closures and so forth. As a consequence, the language itself took on a flavor that, while outwardly mirroring the syntax of Java, C and other Algol based languages, actually was moving towards a declarative model that made for some incredibly powerful programming ... and not coincidentally towards a model that was far more efficiently implementable.
The Power of V8. Google released the first Chrome browser in 2010, and in the space of three years managed to do what Firefox, the reincarnated version of Netscape Mozilla, never quite managed to accomplish - it shoved Microsoft out of browser dominance, and in the process laid the groundwork for a full frontal assault on the software giant. One of the key pieces of that strategy was the re-engineering of the JavaScript engine, using virtualization techniques and some incredible design efficiency to make JavaScript not just a bit faster, but comparable in speed to compiled languages such as Java or C++. This, coupled with similar changes in the browser DOM, set off a mad rush by the other vendors to overhaul their JavaScript engines, and all of a sudden, JavaScript-based web applications were becoming sufficiently sophisticated that they made stand-alone applications begin to look positively dowdy in comparison.
Node.js. This in turn made possible something that had been talked about for years but at best poorly realized - a JavaScript based server platform. While JavaScript had been quietly taking over the browser client space during the 90s and 00s, the server side has seen a plethora of languages come and go - Perl, ASP, PHP, Python, Ruby on Rails, ASP.NET, the list was fairly long and made for fiercely partisan camps in that space. However, after thinking through a lot of the philosophy on threading, closures, and asynchronous development, Ryan Dahl took the V8 chrome engine and used it as the core for a generalized server language in 2009. This engine caught on rapidly - partially because there were a lot of developers who were used to working with node.js on the client, and found that the same toolsets and skills that worked there could then be applied to the server side. As a side effect, the number of JavaScript libraries exploded, taking advantage of an installation mechanism (npm) that mirrored Ruby gems. Node.js was also more than just a web scripting language - it could be used for running scripts that could work on internal system objects and communicated with the next major shift in development, the rise of NoSQL databases.
NoSQL. The 1990s saw the rise of the relational database, and traditional SQL databases played a big part in the way data was stored through the late 00s. However, one of the major side effects of AJAX was a fairly fundamental shift in the way that data was treated. Prior to then, most applications communicated with a SQL database through some kind of recordset abstraction layer, and the 90s especially were littered with three letter data access layer acronyms. However, one of the things that began to emerge once AJAX came into play was that data was seldom flat - it had structure and both clearly defined and not-so definitive joins of various kinds, and more often than not more closely resembled a document rather than simply a bag of property values. About this same time, data in motion really began to become more broadly important than data at rest, and for that reason the denormalization of data that was typically involved with such structures began to seem archaic when those structures already had clearly defined, and multi-tiered, layers.
NoSQL databases - a wide gamut of non-traditional databases including XML, JSON, name/value, columnar, graph and RDF stores - had been percolating in the background during much of the 00s. As system performance improved, these stores (which usually embedded not just single tables but whole DOMs) began to relied upon, first for document-centric information, then later for data-centric. AJAX gave them a much needed push, as being able to store complex data structures directly without having to reconstruct implicit joins reduced the overall data access burden considerably, and also moved much of the computing world to a more resource oriented (or RESTful) mode of operation.
Many of these systems are designed to work with JSON in one form or another, and increasingly JavaScript forms at least part of the query and update chain. Additionally, even in XML data stores, the endpoints are becoming JSONified. Efforts are underway to take the powerful but underutilized XQuery language and make a JavaScript binding layer to it as well.
Map/Reduce. Google's search capabilities are made possible primarily by creating massive indexes of the web. The technique for building these indexes in turn comes from a powerful application of a concept called map/reduce, in which incoming data (such as web pages) is mapped into large blocks, each block is processed for indexing, then the subsequent indexed content is reduced into a single indexed data set. By splitting the content apart then reintegrating, such a process can be transformed into multiple parallel processes, each running on its own real or virtual server space with dedicated processors.
Hadoop, perhaps the most well known of the map/reduce applications, is written in Java. However, increasingly other languages, including most notably node.js have built their own Hadoop-like map/reduce system, and JavaScript, which has a remarkably fluid concept of arrays, objects and functions, is in many respects more ideally suited for M/R type operations - it is a language built upon asynchronous callbacks, dynamically generated objects, functions as arguments and distributed data. Given its ease of use compared to Java, which still retains many artifacts of a strongly typed language, in such environments, JavaScript in node.js has a very good chance of dethroning the Hadoop/Java stack as the preferred mechanism for doing rich M/R.
HTML5, Android and Mobile. The HTML specification was, for all intents and purposes, frozen at version 4.0 in 1997. Several proposals for expanding outliers to the language - a graphical language (or two), CSS for layout, video and audio, new controls and so forth - had been building up in the background, but it was ultimately a decision to create a new version of the specification by outside groups that ended up providing the impetus to try to tie all of these pieces together. The resulting set of technologies was very sophisticated, including capabilities for managing both 2D and 3D graphics, sophisticated enough that it satisfied several key requirements for a graphical user interface ... and put the final nail in the coffin of third party binary plugins for the browser.
Google purchased the Android core set in 2005, and built on top of that for several years until the nascent smart phone market exploded with Apple's introduction of the iPhone in 2007. By the time the first Android phone was released in 2008, it's Java based operating system was firmly set. However, Java for Google is somewhat problematic - it does not control the technology, and the Android OS has a number of vulnerabilities that arise precisely because of the use of Java.
A number of attempts have been made to create a JavaScript layer for the Android OS by third party developers, and it is likely that had the V8 engine been available in 2008 Google would almost have certainly chosen to go with it rather than Java as its build language; a great deal of any App development comes down to binding existing component functionality, rather than creating such functionality, which is usually hardware based, from scratch, a task which JavaScript excels. While Google tends to be tight-lipped about its current development plans, its not inconceivable that Android 5.0 will end up being written around the V8 core and use JavaScript, rather than Java, as its primary language.
It should be noted that in the context, two of the hottest development applications today are Appcelerator Titanium and PhoneGap, both of which provide a JavaScript environment for binding applications together. These platforms are popular primarily because they are remarkably cross platform - you can build the same application for iOS as you can for Android, while objectiveC and Java by their very nature limit you to one or the other.
There are several good reasons to suspect this. One of them is the fact that HTML5 is now capable of producing more sophisticated user interfaces then many app developers have available to them natively. Such apps could be deployed as a mix of local framework shell and just in time application code (which is essentially what a web application is), and these applications could also take advantage of robust third party libraries that could also be utilized within web clients and JavaScript servers, which in turn reduces the overall threshold for the skills an application developer needs to maintain.
Additionally, the same things that make JavaScript advantageous in web and server development - closures, functions as objects, weak typing, dynamic declarative programming, event driven design - are perhaps even more appropriate for mobile devices and sensors than they are for the relatively robust world of web browsers.
Finally, an HTML5/SVG/CSS/JavaScript stack makes for a powerful virtual machine that can run on phones, tablets, traditional computers and most nearly any other device without significant re-engineering from one device to the next. The current architecture for Android gets close, but it still has problems with applications working inconsistently across devices due to low level considerations.
JavaScript as Services Language. Outside mobile, the next major area where JavaScript is set to explode is in the services arena. JSON has been steadily wearing away at the SOAP-based SOA stack for several years now, as well as the publish/subscribe world of RSS and Atom (both of which now have JSON profiles). Web workers and socket.js are reshaping point-to-point protocols. With JavaScript's increasing dominance in the NoSQL sphere, it's a natural language to handle the moderate bandwidth interchange that increasingingly controls the interactive, as opposed to the high speed communication protocols.
These are all reason why I suspect that JavaScript is likely to make its way into the enterprise as perhaps the primary language by decade's end, if not sooner. Most current metrics give JavaScript a fairly low overall position compared to others (Tiobe.com places it at #11), but this is primarily based upon server side usage in the enterprise, where it's use today is still fairly limited, and due to the fact that the two most popular languages right now - Objective C and Java - are there because of the explosion of mobile app development. A V8 engine built into a future version of Android would rocket the use of JavaScript to top tier fairly quickly. The growing trend towards "big data" solutions similarly currently favor Java, but as JavaScript (and node.js in particular) develops its own stack again I think that this language rather than Java will become as pervasive on the server as it is on the web client.
It's also becoming the common tongue that most developers have in their back pocket, because so much of application development requires knowing at least some web development skills. It may not necessarily be a favorite language, but common languages have a tendency to become dominant over time, and as JavaScript increasingly becomes a fixture on the server, it's very likely that it will eventually (and quickly) own the server.
Thus, when I talk to people entering into the information technologies field today about what languages they should be learning, I put JavaScript at the top of that list. Learn JavaScript and node.js, HTML5 and SVG and Canvas, Coffeescript (which is a very cool language that uses JavaScript as it's VM). Learn JavaScript the way that it's used today, as a language that's more evocative of Lisp and Haskell than of Java and C++. It's pervasive, and will only become more so.
Awesome article!
ReplyDelete