Port RJS to Java. Ugh. i dread this task. I really do. Recreating RJS templates in Java….Yuck. I dread this task because I made fun of the prospect of some Java programmer having to recreate RJS in Java a few weeks ago on this blog, but, I’ve created an application in Rails that must be ported to Java. Don’t ask why, just know that it must be ported to Java. This isn’t the first time, I’ve had to port something from Rails to Java.

So…..errr…..what does one do if your Rails “prototype” makes heavy use of some of the most advanced features of RJS templates and you have to migrate to Java? My first thought: ask the fine readership of this blog if they have found themselves in a similar situation, or, better yet, is anyone out there already doing this? C’mon, I can’t be the only one in this wide world who has been using RJS and wondered, “Why can’t I do this in my Java application?” ….The first step, Google “RJS in Java” - that search returned a few hits, but mostly links to Rails RJS pages and links to blogs bemoaning the fact that Java isn’t there yet.

The real lesson here is “Never prototype with a technology more capable than the target platform.” So, take this as a lesson, if you are using Rails as a prototyping language, don’t use RJS, you’ll end up wishing that your prototyping technology was your production technology. As I’ve said before, J2EE is a trusted, capable platform, and in some ways it is lightyears ahead of Ruby, but, as far as web applications go Rails does laps around Java. So, maybe porting RJS to Java might help level the playing field? Maybe? Who knows, all I know is that I’m not the only only who thinks that Java is not Web 2.0.

Read on for the options…

The Options

Mission: “Port a Rails application to Java”, Caveat: “The Rails application makes heavy use of RJS templates”. Specifically, your application calls RJS templates that send a mixture of freeform Javascript, insertion calls, scriptaculous effects, render _partial calls. What options do I have?

1. Write Javascript Directly (Get out the Rhino book) Just write a series of JSP pages that just alter the response MIME type and send back the appropriate Javascript using Prototype and Scriptaculous.

Unfortunately, I’m gathering that much Web 2.0 development in Java consists of developers coding JavaScript directly, and I’m fairly certain that Java developers haven’t moved past XmlHttpRequest as a data transfer technology stage yet. In fact, the idea that Javascript can evaluate a Javascript response isn’t something I’m seeing in any Java frameworks at the moment, and trying to explain the concept to people not familiar with the approach is proving difficult. Here’s the idea, you are writing Javascript that makes a remote request, the response contains Javascript which is evaluated by the same Javascript that made the remote request. Now dig into the details of RJS and you’ll start to realize that having an abstraction on top of this is essential. I’m not willing to write raw Javascript because I’m not willing to debug raw Javascript; as easy as Prototype makes Javascript - Javascript still sucks

Good AJAX development should require a minimum amount of direct Javascript coding; preferably none. You need to be able to rely on a good set of abstractions and helpers that solve 80-90% of your Javascript needs. In Rails, the Javascript helpers and the Javascript generators make it so that one can create a highly AJAX-ified application without having to write reams of Javascript. You only end up writing Javascript to handle the cases not covered by the helpers, and the Javascript you end up writing is straightfoward.

option 1 - dead on arrival.

2. Recreate RJS in Java. Create an Abstraction Similar to the JavaScriptGenerator in Rails In this approach, An existing servlet/action/whatever would just be forwarding to a “jjs” instead of a “jsp”. A JJSServlet would be invoked which would render a script contained in a JJS script.

I’m leaning toward this option, but I’m also resigned to the fact that this approach is: A. Very derivative of rails, B. Will be limited to a subset of Rails features. The JJS script would be analogous to a JSP page that renders Javascript, I’d be writing some abstractions to approximate the page object, I might have to write some logic that would take care of rendering a partial. In other words, I wouldn’t be looking to recreate the entire set of Rails features, I’d be coding to the requirements of the project in question and porting over features as I need them.

….and, the whole time, I’ll no doubt be thinking, “you know, if I could just do this in Rails, it would’ve been done ages ago”. Porting derivative technologies is never very satisfying, you always end up playing catch up.

3. Use another framework, something like Google Web Toolkit.

I could just opt to use Google Web Toolkit, and this is an option I’m going to look into, but the problem here is that I’m not interested in such a dramatic change. What I want is the ability to integrate a Javascript response in the middle of an existing Java web application. I worry that the adoption of Google Web Toolkit is going to just create a whole new level of abstraction that I’m not interested in adopting. But, it has to be said, Google Web Toolkit is to Java as RJS is to Ruby, but methinks that Google Web Toolkit goes a bit too far. From what I can see GWT isn’t something that augments an existing web application, it takes it over.

Conclusion

So there you have it, I’m leaning toward Option #2 and am beginning to think that it needs to be open source for the good of Javaland. Anyone have any input / suggestions?