No popular language may be as maligned as JavaScript. But its migration to the server side opens the possibility it may become all-pervasive
In 1995, when Netscape was looking for a new brand for its browser-embedded scripting language, the company licensed a variation of the “Java” name from Sun Microsystems. JavaScript was born, creating a mistaken impression (that of JavaScript and Java’s close relation) you’ll still see some newbs trip over to this day. That shared branding deal would never happen now; the executives at Oracle never watched “Sesame Street” as kids, so they don’t share.
As time wore on, Java in the browser withered, and if Google hadn’t rescued client-side Java with Android, it would be dead on mobile devices, too. JavaME has always been equal parts technical disaster, marketing faux pas, and dubious value proposition: You want me to pay what to embed that? Meanwhile, JavaScript, despite Microsoft’s best efforts to make an incompatible mess out of it, has become the cross-platform language of choice for application developers and platform developers alike.
JavaScript invades the server
Originally a client-side language, JavaScript made quick inroads on the server side. Microsoft offered its JScript fork as an option in Active Server Pages in 1996. In the early part of the last decade, I worked on an Apache project called Cocoon, which was based on XML transformation pipelines. Stefano Mazzocchi, the project’s lead and an early mentor of mine, pushed to embed JavaScript into Cocoon as a sort of control language. I thought he was flat-out nuts, but in the end it turned out to be a better idea than developing dynamic websites based on XML pipelines.
Rhino was one of the first embeddable scripting languages for the Java Virtual Machine. While it was originally intended for Netscape’s abandoned rewrite of its popular browser in Java, it saw mostly server-side use. This snowball rolled downhill until today, when we have Node.js being adopted throughout the cloud as a language for applications. You know you’ve hit it big when someone makes a teddy bear parodying your fanboys.
JavaScript? You gotta be kidding
JavaScript has long been derided as a big ugly mess. This is mostly due to the poor browser implementations that are slightly incompatible. Microsoft, I’m mainly talking to you: IE still sucks when it comes to JavaScript. Nonetheless, AJAX — thanks, Microsoft! — caused JavaScript to become what a high percentage of modern-looking websites are “mostly” written in.
JQuery became the , and most other attempts at client-side browser embedded technologies (read: Silverlight). Meanwhile, Appcelerator, PhoneGap, and other similar frameworks have made cross-platform mobile development a matter of JavaScript programming. Only the most delusional of Apple fanboys actually think they like Objective-C. Uh, the ’80s called, and it wants its programming language back.
Meanwhile, Adobe proved with ActionScript — an implementation based on the “standardized” version of JavaScript called ECMAScript — that JavaScript doesn’t have to suck and you can create decent development tools for it. Unfortunately, Adobe tied ECMAScript to its doomed Flex toolset and weird Flash platform.
The syntax of object literals in JavaScript, JSON (JavaScript Object Notation), is now a language-independent data format and has largely displaced XML for data transmission. Even SOAP/WebServices shops tend to support an alternative JSON syntax. It is terser and far faster to parse in the browser and other clients. Besides, who wants to read SOAP headers anyhow?
Meanwhile, the NoSQL revolution has not only made Oracle stock a dubious long-term retirement investment, but it has also brought us the growth of document databases. What do most document databases, such as MongoDB and Couchbase 2.0, use as their primary database format? Why, JSON, of course!
The winner by default?
All this means we don’t need any other language to write our Web or mobile applications. You can write the client in JavaScript using the jQuery library (with HTML markup, of course), transmit to and from the server in JSON, and store and query your data in JSON in the MongoDB document database — and deploy it all to the cloud. From a management perspective, this means one set of developers, who are often cheaper than Java, Ruby, or .Net developers.
Is this approach all it’s cracked up to be? Node.js has its rough edges. It is single threaded (that is, single processor core) per process and has an option to deploy with multiple processes. This doesn’t scale as well vertically, so buying a bigger, badder machine may not improve performance much. But it may not matter in the cloud, where you can simply deploy more and more instances.
So all JavaScript, all the time is entirely possible — you just need to decide for yourself whether it’s a good idea. For a sample JavaScript application, have a look at Granny’s Addressbook; I’ve included the code for your perusal. (The Java Spring version of this app was used in my comparison of platform-as-a-service offerings, “Which freaking PaaS do I use?“)
The manager in me loves the idea of being able to have a pool of developers who can do JQuery, Node.js, and maybe light database work on MongoDB. The developer in me cringes at the idea of spending my days writing JavaScript, mainly due to bad memories of IE. The project lead in me cringes at the thought of a bunch of JavaScript developers even thinking about my precious database.
On the other hand, I’ve spent enough time coding ActionScript for Adobe’s now abandoned Flex platform to see the utility — and my experience working with JavaScript on document databases has been absolutely great. But do I really want to take that JavaScript mess from the front end and use it in the middle tier? I’m still on the fence.
