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.
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.
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
Picking an Android phone can be difficult, but we're here to help. These are the top Android phones you...
Confidence in our power over machines also makes us guilty of hoping to bend reality to our code
To root out persistent hackers, sometimes you have to get a little creative
In the next five years, half of the crazy new stuff you've heard about will arrive. The other half will...
Jetbrains' statically typed JVM language also offers several bug fixes and other small changes ...
The Apache Ignite in-memory computing platform not only boosts performance, but also adds SQL queries...