JavaScript: are we missing out?

JavaScript will not be ignored. The gangly, awkward adolescent of yesteryear has come of age as a confident, capable and free-willed 18-year-old - crashing your metaphorical party and turning the stereo up to 11. Much to the disdain of your "formal" friends (like the C#/Java clique), it embraces a relaxed, low ceremony approach to getting stuff done. JavaScript is cross-platform like no other language, not constraining its ubiquity to any given technology stack or even paradigm, and it spreads the love evenly.

Once chained to the browser, and relegated to animation and Ajax exclusively, the unwitting introduction of Google's V8 JavaScript engine for Chrome set a course of action in motion that broke JavaScript's angle-bracket shackles, letting it loose on the world. JavaScript can be found on the server, database, and embedded devices - all above and beyond still ruling the browser.

While JavaScript has been an essential part of Web development since September 1995, it was only 13 years later that Google developed and introduced its V8 JavaScript engine, recognising that JavaScript was bursting at the seams of browser performance, and seeing the desperate need for it to grow, says Mike Geyser, developer at BBD.

This decision was a catalyst for what followed, with the NodeJs project releasing a re-tooled, server-side JavaScript framework reliant on V8 less than eight months later, followed by a rumbling avalanche of rich-client JavaScript frameworks all climbing onto the HTML5 train - each attempting to outdo the last.

With this avalanche in full roar, it is at times difficult to separate the signal from the noise, and figure out where the hype begins and ends. JavaScript itself has not remained stationary during this time; the ECMAScript specification has trundled along, albeit at a sedentary pace, and the W3C is constantly including more APIs that are accessible to JavaScript, such as local storage, audio, video, hardware, and Web sockets.

Between the auto-include jQuery library and the almost flavour-of-the-week proliferation of SPA/MV* frameworks (AngularJs, Ember, KnockoutJs, Backbone, BreezeJs) you can barely turn around on the Web without running into an excellent, richly-interactive Web application built using the 'next big thing'.

The largest technology companies are all relying on JavaScript heavy Web applications to drive their 'next-generation' user experiences, and the enterprise is following suit. Demand has risen sharply for rich and responsive user interfaces that have a high reach and a very small footprint, moving away from traditional desktop applications and taking their business into the cloud.

The choice of framework is still a contentious and clouded issue, and the variety and excellence of these client-side JavaScript frameworks only serves to make the decision harder. While the client side landscape is inundated with choices, it is the *nix-like, single purpose nature of most JavaScript libraries, allowing them to be used as composable building blocks, that makes the platform a pleasure to develop for. If you need complex time manipulation: use MomentJs. Need OAUTH? Use PassportJs. Need backwards compatibility with IE? Use modernizr. The options are endless, and result in JavaScript being a build-your-own-framework platform, where you choose what you need and only what you need.

As with any coming of age story, it is important to know the boundaries and rules, and JavaScript is no exception. The world has woken up and realised that the Web is no longer the wild west of the 90s, and to write complex and scalable applications in JavaScript is going to take discipline. Alongside the hype of new frameworks is the steadily solidifying base of emergent JavaScript design patterns, many of which are direct extensions of the traditional 'Gang of Four' patterns. It is also essential that one identifies one's weaknesses, and there are many object-oriented concepts and practices that can have no real analogy in JavaScript. Rather than condemning the language, myriad projects have evolved, like CoffeeScript, TypeScript, Dart and Google Web Toolkit to create specialised languages that compile to JavaScript and lead to the sense that JavaScript has become the assembly language of the Web.

Unlike many technology trends, JavaScript has a long established track record, and many major players on the open Web already rely on it heavily. Even its more experimental forms, being server and database bound, are met with great success.

Yahoo, Paypal, Ebay and Microsoft Azure are among those that rely heavily on NodeJs for critical systems, and Forbes, IBM and CERN are among those using MongoDb for 'big data' - all big companies taking the leap and reaping the rewards. Full-stack JavaScript has empowered some of the biggest Web companies to not only rapidly prototype, but improve programmer productivity, and even performance. Paypal, as a recent example, rewrote its Checkout functionality using full-stack JavaScript (a not inconsiderable risk as it is the core business function responsible for generating revenue in excess of $3.5 billion) and reports hyperbolic success. Paypal claims its project teams are 1/10 to 1/3 smaller than on its old stack, with a reduction in lines of code of a factor of three to five. The glorious cherry on the cake is that it has increased its production throughput tenfold by running on NodeJs. While we all agree there is no such thing as a silver bullet in software, success breeds success, and the enterprise is starting to recognise that what works on the open Web can work for it.

Playing on the server is still an away game for JavaScript, though, and it's only on its home ground that JavaScript really dominates: in the browser. The zealous fervour of the HTML5 movement is driven by the thrumming engine of JavaScript, not by the addition of a couple of semantic HTML tags. As much as the W3C has done for the acceptance of HTML5, it is the continued excellence of client-side JavaScript frameworks that has contributed to its meteoric rise. JavaScript has moved from being an 'ancillary' skill set on a developer's CV, to being a core concern. Being versed in purely a server-side language is no longer good enough.

So everything needs to be rewritten as JavaScript, right? No, wrong. The conventional software stacks are by no means being obviated, and varied skills in these technologies are more relevant than ever. The Java virtual machine and .NET framework still have much more stability and straight-line speed than NodeJs (which has not hit v1 yet), and their operationalisation is something that is well understood.

JavaScript plays well with others and can augment existing software stacks where it fits the problem, but it takes a keen eye and an informed mind to determine when it is the right solution. Whether on the client or server, and used judicially, JavaScript can bring a modernising element to a software solution, elevating it from simply another line-of-business application to something that stands above the rest. JavaScript will not be ignored, and will continue to grow from strength to strength, and right now it's kicking down the door of the enterprise.