I've been experimenting with using Rhino (Mozilla's JavaScript interpreter written in Java) on top of Java servlets (Tomcat, in my case). After working through a few issues it's working pretty well. You can even compile JavaScript to Java bytecode for better performance.

Rhino is great because it lets you use all the zillions of Java libraries directly from JavaScript without the Java... dynamic typing, no compilation, etc. I can do things like:

    importPackage(Package.java.io);

    var writer = new FileWriter("hello.txt");
    writer.write("Hello world!");
    writer.close();

"After working through a few issues it's working pretty well."

Can you please elaborate so that we can learn from your experience?

Mostly silly Java things like classpath issues. Also, to get importPackage() you need to do:

    Scriptable scope = new ImporterTopLevel(context);

instead of:

    Scriptable scope = context.initStandardObjects();

But now I'm having problems getting John Resig's env.js (a browser environment emulator) working because it uses getters and setters, which are new to Rhino 1.6R7. I thought I was using the latest version (it's the one in both JAVA_HOME/jre/lib/ext/js.jar and TOMCAT_HOME/shared/lib/js.jar)

Thanks. I don't know Java. So will using Rhino require me to learn at least some?

Yeah it helps to know a little Java to get it up and running, but you just need a little glue to get Rhino talking to the servlet and vice versa.

Plus if you want to use the Java libraries from JavaScript you at least need to be familiar with the APIs (or know how to look them up in the javadocs)

Take a look at Helma if you don't want to deal with all that, it uses Rhino: http://helma.org/

Thanks for Helma. Which book/website would you recommend to gain the minimum Java knowledge needed to effectively use JS+Rhino?

I don't have any particular recommendations for Java books, probably any of the usual "learn java" style books are ok, it's not a particularly difficult language to learn the basics, but I'd check reviews of books on Amazon or something.

I've recently discovered http://www.cafeaulait.org/ and it seems like a good Java resource. And of course http://java.sun.com/

Oh, this is very clever. It's a mozilla-based server-side DOM+Javascript implementation which mediates between a client browser and a backend http server. So you can do DOM manipulation and Javascript processing on the server, the client, or both. It supports connecting to local and remote web services so you can leverage your own backend or an external third-party site. And you can manipulate that DOM before sending the data back to your client! Interesting, very interesting.

It sounds promising as a way to tightly couple your server processing to your client display. Transparently calling between the server and the client is an interesting approach.

My big concern is adding what seems like just another layer in your server stack. Aptana seems to think that Jaxer can replace other server-side technologies like PHP or RoR, but I'm not convinced. I also think that tightly interweaving your server and client could generate some massively ugly code and nearly unmaintainable codebases. Proper separation of concerns could be very tricky.

Now if they'll just get it running on Linux maybe I can check it out.

Reminds of classic ASP, which could actually run JScript on the client as well as the server. However, eventually, this technique results in a spaghetti of UI, logic and DB code - all in one place. Ideally, these tiers should not be tightly-coupled.

Agreed. It also reminds me of current ASP.NET where you can manipulate DOM (as long as it's marked with runat=server) as well, only with ASP.NET you also get super-powers of .NET runtime.

To me it sounds like a bunch of browser/JavaScript dudes are trying to write server-side software, being unaware of how it must be properly written. Seeing SQL surrounded by HTML tags is so late 90s...

The real gains, however, will happen when we'll be able to do it exactly backwards: run typical server-side code (blessed with rich runtime) inside of the browser. Browser's DOM (runtime) sucks. This is why there are so many browser-side runtimes being developed right now: Flex/Silerlight/JavaFX.

Aptana got it wrong.

If we can keep just the UI in the Jaxer<->Browser world with logic and DB elsewhere, then this problem may be alleviated. I think that directly manipulating the DOM on the server, rather than working with raw HTML is the big win. Having the client and the server seeing eye-to-eye on the logical representation of the document being transmitted removes one of the many impedance mismatches in web programming.

Jaxer could be great if someone just made a decent MVC framework and used jaxer for html templates. It's worth to have a look at TrimJunction, a JavaScript port of Rails implemented in rhino http://code.google.com/p/trimpath/wiki/TrimJunction

In my opinion, ruby code is way more readable than javascript. Here's a direct comparison of a rails and a junction app http://code.google.com/p/trimpath/wiki/RubyRailsVsJavaScript...

How does this affect performance? I don't see any mention of unnecessary round trips.