Friday, January 20th, 2006

Ruby in the Browser?

Category: JavaScript, Programming

Paul Hammant says “Bring on text/rhtml on the client side” for Web 3.0:

If the client and server technology were pure Java (say Swing), then a refactoring either using the IDEs functions or good old cut and paste would allow you to quickly move the applicable methods from one place to another.

It got me thinking that for Web2.0 your cut/paste solution is not going work. For the audience in question, Ruby on Rails is the weapon of choice on the server side, but the client remains HTML/JavaScript. Wouldn’t they prefer a future and ubiquitous web-browser environment that allows Ruby as the script language interspersed amongst HTML lines?

As Paul mentions, Rails solves the problem of redundancy by generating Javascript (server-side Javascript is another option.) He discusses the idea of a Ruby plugin, though it’s not clear how it would be any more successful than ye olde Java plugins. How much of a problem is it to use different languages for client and server? After all, this used to happen a lot (and still happens) in desktop systems, where there’s no compulsion to do so.

Of course, it’s not just the benefits of a single language, but also a potentially *better* language. An interesting quote from Charles Lowell:

I, for one, would love to see the DOM scriptable from Ruby. As languages go, javascript and ruby are quite close. I’d even venture so far as to say that javascript is much closer to ruby in spirit than it is to its own namesake.

That said, there are two reasons I would prefer DOM scripting in ruby. The first, and most important is the rich api that comes bundled with it. Even if all I could take with me were Array, Set and Hash, it would be well worth it given the uber-sparse set of builtin javascript objects.

The second is stylistic. A Turing-transexual, javascript is ruby trapped in java’s body…

Posted by Michael Mahemoff at 6:33 am
15 Comments

+++--
3.3 rating from 24 votes

15 Comments »

Comments feed TrackBack URI

I’d like to turn the proposition around on its head.

I suspect that most people still don’t understand the power of closures. The ability to have private methods and variables and to create functions/objects at any point in the code is incredibly powerful. From the few libraries I’ve looked at though, it’s still totally under-utilised.

I agree that working in the same language on client and server would be a fantastic improvement but I would much rather turn the solution around and use Javascript on both.

Are there good ways to run Javascript on the server? Are there good libraries for those implementations?

Comment by Peter Nixey — January 20, 2006

Peter,
Apache Cocoon uses Javascript on the server-side for Web Continuations in the controller for a webapp, but there’s a ton of other layers on top of it. When you realize you just need to write Javascript for a web controller, it ends up working out quite well.

Comment by Tony — January 20, 2006

Asp supports javascript on the server, but not the DOM.
Then there’s Xin, which does support the exact DOM as in the browser on the server.
It’s essentially an exact reflection of the browser on the server, and supports DHTML serverside to the extent that you can actually cut and paste clientside scripts to the server if you wish.
url: http://www.google.com/search?hl=en&q=rich+desktop

Comment by Mikael Bergkvist — January 20, 2006

While I understand that Ruby is the flavour of the month for a lot people, it seems somewhat silly to call for it to be included in the browser. For a start, you’d loose backwards compatibility unless you use a plugin, but once you start using plugins you might as well go back to Flash or Java. But more fundamentally – why does Ruby merit inclusion and other scripting languages do not? So what if “the cool kids” are all using Ruby, most people still use Perl, Python and even VBScript (at least with VBScript, one browser already supports it :-) What happens when Ruby becomes really popular and the language fashonistas move to yet another language?

Comment by Scot — January 20, 2006

i will say this for the umpteenth time – browser scripting needs to become language neutral. be it ruby, javascript, hell, even C or cobol. what is needed is a language independent VM that executes a bytecode format instead of source. let developers compile their language of choice to this VM, which would enforce security semantics etc. the mono vm or one of the open java vm’s would provide this support, among other engines. the DOM bindings themseles are trivial, many lagnuages already have mature libraries.

any platform over time must support language neutrality. look at databases – they all support bindings to various languages now, and some even support other languages directly in place of sql.

Comment by grumpY! — January 20, 2006

I personally see Javascript on the server as the best option available today. In Struts Flow, I’ve implemented Rails-style controllers and by working with Rhino directly, you could fully implement ActiveRecord since, by writing a class that implements Scriptable, you can intercept all method and property calls. I’ve played with building on IBatis by dynamically building queries based on the method name, i.e. findByFoo().

I don’t think you’d want to write the full application in Javascript on the server side, but it does make a great glue layer to handle presentation logic and Ajax calls.

Comment by Don Brown — January 20, 2006

[…] I’ve been reading up about the language-du-year, Ruby. Overall, I really like the language and its seem very capable for web applications. One blog article I was reading had this quote about a possible “Web 3.0″ pipe dream of running Ruby directly in the web browser as a replacement for Javascript: […]

Pingback by Leo Cerebellum Annotare » Blog Archive » Quote of the Day — January 20, 2006

It would be nice to see that happen… really, it has my vote!

One language to rule them all :P

I don’t see problems with compability… most major browsers (except IE) will support it (very) fast.

My only concern would be ‘security’… javascript is safe to use but ruby would be more powerfull and thus not so safe anymore. We need to put limitations on it to ensure safety.

This means also the end of AJAX… ARAX will not replace it ;)

I suggest that we include a new library for server/client communication instead of the XML… this way it would be faster, safer and easier to design Web 2.0 (or must I say 3.0?) application.

The day that somebody writes a decent plugin for this task (or that w3.org start the ‘standardization’ of it) is the day that I leave javascript behind.

Comment by Lesly — January 20, 2006

Doesn’t make a lot of sense to me to try to move Ruby into the web browser any more than it makes sense to replace Javascript with Java or any other random scripting language. DOM scriptability seems to be fairly reasonably attainable through rails and it provides a good level of abstraction from the domain so you can focus on your solution and NOT on the DOM. While Ruby is certainly a good language and has some good language characteristics, I don’t see where this merits trying to build a browser plugin or similar. In reality, what do we REALLY gain from doing this that we cannot already attain using Rails and Dojo/Scriptaculous, etc?

Comment by Gregory — January 20, 2006

Here’s a potentially dumb question: why Ruby and not something that has even better core primitives…like…say…Python? Ignoring for the moment that the suggestion is ludicrous on its face (much like Ruby instead of JS), it’s worth asking why Ruby partisans want *everything* to be Ruby when many other fine dynamic languages exist. I suspect Paul’s desire for a Hash class simply boils down to not understanding JavaScript Objects. The only addition he requires is a Set class (which Dojo provides).

Can’t we just leave well enough alone and accept that JavaScript is *not* going away and that it *is* everywhere and that by god, it’s a pretty darned good little functional language?

*sigh*

Comment by Alex Russell — January 20, 2006

From a practical standpoint, I would rather see an implementation of a Ruby to JavaScript translator. No plug-ins, no weird hacks, no waiting for browser tech to change.

JavaScript is similar to enough to Ruby that a substantial subset of Ruby could be implemented.

This translation could occur on-the-fly or ahead of time.

Comment by Michael Slattery — January 21, 2006

Hi Peter, firecat is a server-side JavaScript Webserver. It’s still in beta, but it is works fine, albeit only on Linux right now. Some features like better support for Ajax might be able to make it into the server before the final release.

Comment by David Fu — January 25, 2006

Sorry about my gramma! I meant to say: “it works fine”.

Comment by David Fu — January 25, 2006

Thanks David and in fact thanks to everyone who pointed out the javascript servers available. I’ll have to do a bit of digging.

Comment by Peter Nixey — January 27, 2006

[…] Finally, some thoughts about ruby as a scripting language in the browser. […]

Pingback by moebius recursive » Blog Archive » Some Quick Links — April 14, 2006

Leave a comment

You must be logged in to post a comment.