Generally, the idea of having the same language on the server and the client side, a common JS context for both the rhino world and the java server world is highly interesting.

What I am not totally convinced of is extending DOM etc to the server side. While the server side wouldn’t have to deal with the same implementation mess as the client side, there could be a lot confusion and a conceptual bluring of the server/client concept.

That same kind of murky thinking that makes people try to use PHP function in onclick handlers etc.

And before we mimic the client side dynamic and have server-side jQuery, Prototype or Moo to replace a server-side DOM implementation that is regarded as too cumbersome from the beginning, maybe there would be a better way to do server-side content-manipulation etc.

The couchdb app thing I was writing was about such ways.. Basically server-side progressive enhancement by widgets that attached themselves to the HTML doc. But as I said it all became much too complicated to continue side-by-side with the work load of my day job.

The one thing that prevents me form using Jaxer is that I need to have my projects run on Tomcat and connect to the database using JDBC…

Well, I keep dreaming about a Rhino based Jaxer .
Regards,

I’ve toyed around with server side js a bit, also as CouchDB app thingie, but all too much work for me to really go through with it. (Except for serverside compression/bundling of js based on rhino which plays a major role in OpenSAGA (http://www.opensaga.de/blog/dokumentation/overview/), our soon to be open-sourced work project.