Recommended: Sing it, brah! 5 fabulous songs for developers
JW's Top 5
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
In 1996 when no one believed in Apple and AOL was voted most likely to succeed, Netscape took its shiny, new JavaScript language from the browser and stuck it in the Netscape Enterprise HTTP server. That was probably the first moment that someone tried to make JavaScript the lingua franca for back-office servers, but it wasn't the last. After Netscape dissolved into Mozilla, new stacks with JavaScript have come and gone as the true believers try again and again.
Now some 15 years later, JavaScript on the server is back in vogue. The buzz from the latest round of believers is that JavaScript is the "new Ruby," for all of the same reasons that Netscape began the trend. Using the same code for the client and the server makes life easier for everyone -- you never know when you'll need to move a routine from one to the other. I can't tell you how many times I've tried to make sure that the Java version of the SHA256 hash algorithm running on the server produced the same output as the JavaScript version running on the client.
[ Also on InfoWorld: 13 open source development projects making waves in the enterprlse. See "Open source programming tools on the rise." | Keep up on key application development insights with the Fatal Exception blog and Developer World newsletter. ]
But some things are different this time. Many of the earlier efforts were built around perfectly nice JavaScript engines like Rhino that offered perfectly acceptable performance. Now we have a number of new JavaScript engines such as Google's V8, which is much faster and uses many of the just-in-time compilation ideas that sustained Java's virtual machines over the years. Suddenly JavaScript is speedy enough that people think of using it for its velocity, not its convenience. It's entirely possible that all of the hard work on the browser engines is making JavaScript the fastest dynamic language and one of the best choices for server-side programming.
To understand the latest burst of enthusiasm, I spent some time installing a few of the more interesting JavaScript servers and building a few basic websites. The tools were all intriguing, thoroughly fun, and oozing -- the software equivalent of a fresh, clean coat of latex paint. This newness cut both ways, though, because some of the documentation was sketchy and many of the demonstrations were not much more complicated than spitting out "hello world."
I enjoyed the challenge and stimulation of rethinking everything I know about the server, but I still found myself hesitant to push these new ideas too far or too fast. These servers are fresh from the lab and made for experimenting, not building an application for Grandma to check the interest on her CDs. The ideal project for a corporation might be a temporary website for a one- or two-day event that would come and go in a flash. For now, enjoy creating something new and fun with them, not betting your business.
JavaScript servers: Node.js
The hottest star is undeniably Node.js, a simple package that is attracting the kind of attention that leads people to roll out the term "fanboy." Blogs such as
How to Node are filled with hints and suggestions as people try to figure out just how far they can push the tool. There's already been
a conference devoted to the project, and people are using the word "node" as a verb that means to write Node.js code. Will
the language still be around next winter for us to make puns about "bad code in the node"? I'm sure the ideas will still be
here because they're powerful, but the names may morph into something else because there's plenty of reinvention in this space.