Lots of developers are understandably concerned about Oracle's recent lawsuit against Google, which alleges that the Dalvik virtual machine in the search giant's Android smartphone OS violates Java patents. While most analysts agree that the suit probably won't affect the majority of Java developers, some coders are so dismayed that they're already looking for alternatives. If that's you, have you considered switching to JavaScript?
Hold on, you say. Any developer with half a clue knows that Java and JavaScript have almost nothing to do with each other. Netscape was originally going to call its browser-based scripting language LiveScript, but Sun Microsystems convinced it to go with JavaScript instead -- the idea being that JavaScript would act as a kind of bridge between HTML and Sun's fuller-featured Java.
But if Sun thought Java would brush aside JavaScript to become the de facto language of the Web, it couldn't have been more wrong. While Java eventually found its niche as a server-side application language, JavaScript trounced it in the browser. Today, projects such as CommonJS and Node.js are extending JavaScript even further, allowing it to take on Java's traditional role in the data center. In a fascinating role reversal, JavaScript is becoming the versatile, powerful, all-purpose language for the Web, while Java risks becoming a kind of modern-day Cobol.
Bridging the client/server divide
Anyone of a certain age remembers browser-based Java applets as clunky, awkward, and slow curiosities that were usually more annoying than genuinely useful. Even Sun's latest attempt at a rich Internet application technology, JavaFX, hasn't made much headway against its more established competitors, including Adobe Flash and Microsoft Silverlight. Client-side Java, it seems, was doomed from the start.
Similarly, server-side JavaScript (SSJS) never made much of a splash, either. Netscape Enterprise Server supported it way back in 1996, but it was an expensive, proprietary product. It soon lost the market to the open source Apache server, and SSJS disappeared along with it.
In those early days, however, JavaScript really was best suited as a lightweight scripting language for Web pages. Compared to other emerging languages of the time, such as Perl and Python, it was slow and quirky, with a limited feature set. Worse, each vendor's JavaScript implementation behaved differently, which forced developers to waste time writing hacks and work-arounds instead of well-formed code.
JavaScript has come a long way since then. The emergence of stand-alone, open source JavaScript engines -- including Google's V8, Mozilla's SpiderMonkey, and WebKit's SquirrelFish Extreme -- means anyone can embed a standards-compliant JavaScript interpreter in their code without reinventing the wheel. Currently, all three projects are engaged in a furious performance battle, with each making steady progress. With its underlying technology maturing at a blinding rate, JavaScript is now poised to achieve what Java never could: to break out of its traditional niche and cross over to the other side. Client-side Java remains stagnant, but server-side JavaScript is back.
Server-side JavaScript gets serious
Modern JavaScript engines can run on their own, which makes them a natural fit for SSJS. But so far JavaScript has been primarily a browser-based language, which means it has lacked certain features programmers expect in other environments. For example, client-side developers are accustomed to loading individual .js files over the Internet, while server-side developers need a more formal way to package complex code bases. Also, JavaScript has lacked a standard library of routine system functions, in contrast to more systems-oriented languages such as C or Java.
The CommonJS project seeks to address these issues. Its goal is to create a set of open, standard APIs for such functions as binary object handling; concurrent threading; file, stream, and socket I/O; system logging; and so on. In addition, it has proposed a standard module format for code libraries and their accompanying namespaces. It's a young project yet, but the eventual idea is that JavaScript programmers will be able to write code to the CommonJS specifications and have it run unmodified on any CommonJS-compliant platform, regardless of its underlying JavaScript engine or OS.
Even more exciting, however, is Node.js, which builds on similar ideas to CommonJS and implements some CommonJS APIs. However, it takes the concept of SSJS to a new level. Its most important innovation is its implementation of an event-oriented programming model for server-side development. That means not only will Node.js programming feel very familiar to client-side JavaScript developers, for whom the event-driven model has become the norm, but it's also ideally suited to Web applications, which rely heavily on parallelism to support multiple concurrent users.
If that sounds like so much hand-waving to you, just consider the Node.js code samples. Its equivalent of "Hello, world!" is a fully functional HTTP server implemented in just six lines of JavaScript.
JavaScript: King of the Web?
Don't expect JavaScript to topple Java from its throne just yet. There's a lot of work to be done on both CommonJS and Node.js, and it would be accurate to describe both projects as experimental. What's more, the specific optimizations and management tools that come with Oracle's JRockit JVM, for example, will make Java an attractive platform for enterprise software development for some time to come.
Still, the benefits of JavaScript as a server-side language are clear and striking. It allows Web application developers to implement their entire code base using a single syntax, reducing the clutter and confusion of typical Web apps. JavaScript's performance is increasing at a breakneck pace, which has built-in benefits for developers. Its event-driven programming model makes building parallel applications easy and logical. And JavaScript itself has matured into a fine language, with features that support both the object-oriented and functional programming styles.
There's something else worth considering: JavaScript is completely free and open, maintained by an ECMA standards committee based on contributions from vendors across the industry. While the ECMAScript working group has become deadlocked in the past, it has largely managed to overcome those problems, and the evolution of the JavaScript language continues apace. Meanwhile, Java, while ostensibly open, remains burdened by the somewhat dysfunctional Java Community Process, and now by the threat of potential lawsuits from Oracle. If Oracle doesn't recognize this distinction, developers surely will.
Theo javaworld
