Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Will the future be written entirely in JavaScript?

Andrew C. Oliver | Oct. 10, 2012
No popular language may be as maligned as JavaScript. But its migration to the server side opens the possibility it may become all-pervasive

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 Swing 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.

What do you think? Will the future be written entirely in JavaScript?


Previous Page  1  2 

Sign up for Computerworld eNewsletters.