JavaScript conquers the server

Node.js, Jaxer, EJScript, RingoJS, and AppengineJS combine the familiarity of JavaScript, low overhead, blazing speed, and unique twists

1 2 Page 2
Page 2 of 2

All of this means that the experience is much closer to writing some combination of Ruby and Java instead of creating JavaScript the way it's practiced by people who chain together jQuery calls for clients. EJScript is a viable product that can be used to build serious websites. The EJScript structure is well suited to compartmentalization, in part because it echoes one of the most common and popular architectures.

This tool is probably best for folks who are well-steeped in both Java and JavaScript. The ideal home may be a project that requires plenty of duplication in the code that runs on the client and the server but a significant amount of structure and business logic on the server.

JavaScript servers: RingoJS
Combine the Mozilla Rhino engine with the Java Web server core and you have a mechanism for building a website using JavaScript. RingoJS, like EJScript, embraces the MVC paradigm and echoes many of the common structures used by Java and Ruby programmers. The difference is that the JavaScript is not enhanced with the same object-oriented or syntactical conventions as in EJScript.

The process is similar to building a simple JSP-based site. Perhaps more than many of these other frameworks, RingoJS reflects its Java heritage. There's a fairly complete collection of modules, including ones for profiling and security. Many of these seem similar to their Java counterparts because they're relatively thin layers on top of the Java. The logging, for instance, uses the Simple Logging Facade for Java (SLF4J) to connect with Log4J.

Creating websites with RingoJS was fun but often left me wondering why I shouldn't just code in Java, the common tongue for most of the foundation. If you have enough experience with Java, you'll probably feel the same way. RingoJS isn't meant for people like us. We're probably better off writing code that's closer to the metal.

I think the ideal users will be people who enjoy JavaScript because it's a dynamic language that's a bit more relaxed than Java. RingoJS might be good for a shop where some of the programmers are JavaScript junkies and some are experts in server-side Java. This would allow the two groups to code alongside each other. Those who know JavaScript on the client can now write JavaScript that can leverage all of the power of the Java server stack. The others can write Java.

JavaScript servers: AppengineJS
Let's imagine that you admire the stability and flexibility of Google App Engine's Java runtime, and you enjoy the straightforward nomenclature of Google App Engine's Python API, but you have the need to write your code in JavaScript. If you fit in the center of this Venn diagram, then AppengineJS is for you.

Some clever folks have combined the Rhino JavaScript engine written in Java with a thin layer of an API that uses the Python names. It all rests on top of the Google App Engine Java API. The result is similar to what you might write in Java or Python for the Google App Engine, but it uses the JavaScript syntax.

The ideal users will be those who love the Google App Engine model and its support for quick-scaling applications but can't bring themselves to program in either Python or Java. Now you can write directly to the App Engine API with JavaScript.

JavaScript servers: Stability vs. innovation
This review skipped over a number of different engines and approaches, in part because many of them are fading or at least being eclipsed by new projects. One developer referred to CommonJS, an attempt at building a standard server-side API, as "so 2009." This is how quickly things are morphing. The Java and C programmers might say, "That's so 1995," but their old code from 1995 will probably compile and run even when it uses deprecated functions. Such long-term stability is not yet part of the game here because everyone is having much more fun reinventing tomorrow. Many of the most creative developers seem happy to coin an entirely new name, rip out some of the most useful guts from the old projects, then build something that's sort of new and sort of old at the same time.

Some people who watch the changes see a pendulum that may eventually swing back. Tom Robinson, one of the developers who created the Narwhal framework several years ago, feels there will be some retreat from the callback style that's popular with Node.js devotees right now.

"I'm increasingly convinced this asynchronous callback style of programming is too difficult for most developers to manage," Robinson said. "Without extreme discipline it can easily lead to 'callback hell,' with deeply nested callbacks and complex code to implement logic that would be simple on a synchronous platform."

What's next for him? He sees the older framework being rethought and reworked using the best ideas from Node.js. In place of callbacks, he sees ideas like "promises," "co-routines," "actors," and other objects that hang on to the information in the variables for use later. These objects may be easier to juggle than the callbacks.

That may come to pass with the next generation, but for now most of the interest is in Node.js because of its extreme efficiency. The attention focused on the project must be almost embarrassing sometimes. Some people are treating the Node.js creator, Ryan Dahl, like a rock star. One Q&A interview on the product veered into discussions of whether Dahl really thought "Bridget Jones's Diary" was the best film ever. (For the record, he said it was "definitely top 10.")

The speed of experimentation and development is heady and exciting to the open source crowd, but it will probably seem scary to corporate developers who like the long, stable lives of tools from Microsoft or Oracle. Some of these platforms will probably morph three or four times over the next few years, something that won't happen to the good, old JSP standard in the Java world.

I've often found myself wondering how the Java world might steal some of the ideas for Node.js, as they have with so many other projects. Just as Grails and Trails imitated Ruby on Rails, there's no reason why someone can't build a subset of the JSP standard that will run in a single thread.

One of the biggest problems with using any of these tools for projects with a long life is that the new versions are constantly improving and not much energy is invested into maintaining compatibility. The developers are on the barricades running a revolution, not spending too much time worrying about long-term stability and success.

George Moschovitis, one of the developers of AppengineJS, said that all of this means that he wouldn't recommend any of the tools for serious production work because they're "too immature." But he adds quickly, "I would heartily recommend Node.js and others for prototypes and basic enterprise projects." He notes that projects like Harmony, CommonJS, and Node.js may "change this in the midterm."

In other words, these tools work well for basic prototypes. They're quick and relatively stable. If things go well, they may prove to be ready to add bits and pieces of real responsibility to the programs. When that happens, the projects will slow down and the feature sets will begin to freeze as the users start demanding stability and bug fixes over experimentation and innovation.

This article, "JavaScript conquers the server," originally appeared at Follow the latest news in programming and open source at For the latest business technology news, follow on Twitter.

Copyright © 2011 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a low-code development platform