Many web developers that have only worked with Javascript on the client-side seem to forget that the limitations they are used to inside the web browser and the DOM, do not apply when using Javascript on the server-side. For example, with Helma on the server-side, you can make use of any Java libraries. There is probably no language that has a wider range of available libraries. To instantiate an object from a Java class in Helma you could simply use something like:

On the server-side you are in control of the environment in which your application runs, which means you do not have the compatibility issues you are used to from the web browser. Also, you do not need to wait for new technology to be adapted by the user community. So, on the server-side you can always make use of the latest Javascript features. For example, you can use E4X because you would know that your server-side environment supports that.

Another example is being able to extend the Object and Array prototypes without worrying about breaking for/in loops, like is currently the case on the client-side. That ability alone allows you to bend Javascript in the directions of your preferred coding style and makes it incredibly flexible.

What you cant change, of course, is the curly braces syntax. But I think the fact that it shares that syntax with the two big languages C and Java is ultimately Javascripts big advantage that makes it a good companion in these environments.

In his
JavaScript as a Language
blog post, John Resig writes that Javascript is ready for its next phase, breaking out from its traditional habitat inside the web browser. In this regard, he thinks two projects have really stood out as having a lot of potential.
Rhino on Rails
and Helma.

John says about Helma: "This web application framework is a long standing stalwart of server-side development with JavaScript (again, using Rhino). Surprisingly, its managed to fall through the cracks with just about every JavaScript developer that I know. I recently noticed it, and after some startup friends of mine revealed that theyre developing an application based on it, I became convinced that well be hearing about this little framework in the upcoming months."

Of course, Javascript has been used on the server-side in many products ever since Netscape used it in its server-side offerings. What makes Helma special, is that it is for "Javascript as a Language" what Django is for Python and what Rails is for Ruby. In fact, Helma probably was the first Rails-ish web framework, offering an agil development approach and code-less mapping of objects to database tables, long before there even was such a thing as Rails.

Back then, I thought that Javascript was so much stuck in browser-centric preconceptions that we could never redefine what "Javascript" was perceived as and that we should switch to using the language's original project name "Mocha" when talking about it outside the web browser. Later, the Ajax hype came along and proved that it is possible to redefine the way the language is perceived. Generally, Javascript is still seen as a client-side language, but I think we know now that this can change quickly :-)

"When you start digging into Rhino, you find unexpected depth. JavaScript (unlike Perl, Python and Ruby, at least today) actually has a real specification, and Rhino follows it rigorously, aiming for complete SpiderMonkey compatibility within the bounds allowed by the different language platforms. Rhino also offers rich configurability, has well-defined multi-threading semantics, has a full set of hooks for debugging and profiling, and much more besides. There's a lot under the hood."

About building on Rhino, he says... "keep in mind that this is server-side JavaScript we're talking about, and on the JVM to boot. So libraries aren't an issue; there are plenty. And browser incompatibilities aren't an issue either - there's only one Rhino, and it works as advertised. But we've been able to go a step further and make some fundamental extensions that have made it almost Ruby-esque."

Interestingly, the example he picks is regarding the enumeration of methods and properties extending the Object and Array prototypes... "in client-side JavaScript there's currently no way to define a property that's non-enumerable, which implies that you can't add new functions or properties to Object.prototype, since they'll suddenly start showing up in your object literals (which are JavaScript's hashes, more or less). But in Rhino you just create a Java method that calls into the Rhino runtime to define non-enumerable properties, and you can extend Object.prototype to your heart's content. So we went wild, and added pretty much every interesting Ruby (and Python) built-in method on the built-in classes (Object, String, Array and the like)."

Steve Yegge says that quite a team inside of Google has gathered by now, investing their 20% time into future Rhino development. Very Cool! I think that's probably the best news about the whole story - because on the Rails port side of the story, it seems he didn't really address the most interesting part, ActiveRecord, and they are instead planning to go in the direction of Hibernate.

He makes it clear that the project is not at a stage where it could be open sourced, and that that won't change much for at least a year. It looks like they will keep their eyes open for Rails-ish web frameworks of the likes of Helma.

Amongst many other improvements, this release includes the new parameter collections req.postParams, req.queryParams, req.params, and req.cookies in addition to req.data, and adds support for monitoring file upload progress.

Your email address:
The "Decentralize" Newsletter
Exchanging ideas for building a
decentralized fabric of society.
Making true democracy work on a larger
scale while decentralizing "everything",
benefiting from local diversity and
global synergies at the same time.
http://tinyletter.com/zumbrunn