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.
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.
Read more about application development in InfoWorld's Application Development Channel.