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.

[ In other Java news, InfoWorld's Neil McAllister examines the Oracle-Google lawsuit -- and his verdict may surprise you. | Keep your Java skills sharp with our JavaWorld Enterprise Java newsletter. ]

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.