Ruby in the browser: a crazy idea whose time has come

This point of this blog post is first, to explain why I think the seemingly nutty idea having ruby execute in the web browser is actually a good one, and second, to show how you can actually do it. Today. It might be a little long, but bear with me.

I've been spending a lot of my free time over the past few months with various different approaches for getting ruby to work inside the web browser. The obvious question would be: Why? Let me start by stating this unequivocally: I do not hate Javascript. I've more than once argued that we as programmers have given not javascript nearly the respect that it deserves. In fact, it was only through treating javascript with respect that I arrived at the conclusions that brought me here.

A few months ago I was working on a project where we needed to move some reasonably complex business logic from the server to the client. The requirements were such that we just couldn't call the logic on the server and have the application behave as desired. I decided to try to use it as an excuse to improve my javascript skills. I used the object oriented features of Prototype, and some visual effects and the unit testing framework of Scriptaculous. To the best of my ability, I tried to approach it my javascript the same way I would any of my "main" development languages. I wrote the code using test driven development and attempted to make it as clearly communicative as possible. And you know what? I actually enjoyed it quite a bit. I was pleased with the code and the users seemed to like the result. I came away with a greatly improved opinion of javascript.

But something I observed bothered me: I ended up creating exactly the same classes in javascript as I had in server side language (in this case Java). This really shouldn't be surprising, since I used test driven design on the server side java code and the client side javascript code it only makes sense it would lead to a similar outcome. But duplicate code has always been (for me) the number one code smell that indicates a need to refactor. As far as I can tell, in order to get rid of this kind of duplicate code I need to develop my core business logic in a language which can execute on both the client (web browser) and the server. I mentioned earlier that I don't think javascript is a bad language, it's not very common for server side development right now and not my first choice. Currently my favorite language for server side code is ruby. If only ruby could execute in the browser. Pure fantasy, right? Believe it or not, there are actually at least 3 possible ways to do it.

JRuby

First up in my explorations was JRuby. Quite a while back there was an experiment by Dion Almaer to a JRuby applet to execute ruby code in the web page. While this was a nifty experiment when I tried to push this idea further I hit one brick wall after another. The first is that the current JRuby implementation does a lot of things that require additional privileges which means a signed applet. The second which proved more formidable is that javascript code can't call privileged java code at all. This meant that having javascript interact with my ruby code was out. Not good. Though JRuby is near and dear to my heart, this limitation, along with the potential barrier to entry of requiring the Java plugin seemed to make this not a promising solution for what I'm trying to do.

HotRuby

So I gave up on the idea for awhile, until I recently came across HotRuby. HotRuby is a Ruby VM written in javascript. It's a fascinating idea, and it actually works. Under the covers it's really a javascript interpreter for the YARV instruction set. It requires Ruby 1.9 since it depends on YARV. There is a script which dumps out the YARV instructions for a Ruby file in json format. In the browser you include the HotRuby javscript which creates a HotRuby javascript object which executes the jsonified YARV instructions. I installed 1.9 on my machine and checked out the HotRuby code from SVN. In a few hours of playing around, I was able to get it talking with prototype.js and had a simple example where i assigned a ruby block to an onclick event of a button. Although the project seems fairly experimental at this point, it shows great promise. In fact, I was getting ready to blog about it when I came across:

Rubyjs

Rubyjs is a ruby compiler that outputs javascript. It requires only Ruby 1.8.6 and installs as a gem which made it easy to get up and running with. Be aware, Ruby 1.8.5 will not work with it, which meant I had to upgrade. Rubyjs leverages another gem, ParseTree, which parses ruby code intos-expressions, which are kind of like a syntax tree. Rubyjs then emits javascript based on these. A bit more complex but seems to work well and can support more of Ruby than HotRuby can so far.

So far Rubyjs seems to be the most viable solution to me. And if you've made it this far into the post, you deserve to be rewarded with some code. To get running is easy, just gem install rubyjs. This will give you a rubyjs command which will take your ruby code and output javascript for it. Rubyjs comes with a few examples but none which really did what I was interested in doing. I wanted to show a simple block of ruby code listening to a button's onclick event. It took a bit of delving into the rubyjs code to figure out how to do it but I think the resulting code came out to be fairly understandable. Here it is:

class DOM
def self.find(element)
  `return document.getElementById(#<element>);`
end
end

class Button
def initialize(js_element)
  @js_element = js_element
end

def onclick(&block)
  element = @js_element
  `
    if (#<element>.addEventListener) {
      #<element>.addEventListener("click", #<block>, false);
    } else {
      #<element>.attachEvent("onclick", #<block>);
    }
  `
end
end

class Main
def self.main
  button = Button.new(DOM.find("button"))
  button.onclick { puts "clicked!"}
end
end

I create a simple DOM class to help me find an element by id. This shows how you talk to javascript code in rubyjs: by enclosing your javascript code in backticks. Rubyjs does automatically maps javascript objects to ruby and vice versa. I'm not going to delve into the nitty gritty of this too much, I'll do so in a later post.

The more interesting class here is Button. A Button instance gets pass in a DOM element in initialize and instances of button have a single method onclick which receives a block. As you would expect, this allows you to set the onclick handler of a button using a ruby block. The code in the onclick method of Button is also interesting: it shows how you can pass ruby objects into javascript (the javascript code I ripped of from Prototype to do cross browser event observing). Rubyjs will interpolate the javascript code in backticks and replace # type declarations with local variables converting the ruby objects to javascript as appropriate. What this means here is rubyjs is transforming our block into a javascript function for us. Pretty cool, eh?

To see this action, we'll need to compile this ruby code to javascript. The command to do it:

rubyjs button.rb -m Main -d -o button.js

The options tell rubyjs to compile button.rb to button.js. Rubyjs also needs an entry point, which is what -m Main is about. It expects Main to define a class method called Main. Very javaesque, but this is a minor gripe. You can see this code in action here.

There's a lot more to talk about with rubyjs, and I plan this to be the first in a series of posts about it. As part of the project there is also the beginning of a port of GWT to ruby. Altho the code is a bit to javaesque for my tastes so far (as you might expect for a direct port), the idea is very interesting. Let me also issue a giant thank you to Michael Neumann for writing rubyjs and for being incredibly helpful and responsive while I was experimenting. When I asked a question he posted a new version of the gem to address my concern within a few hours. Impressive.