Paul Hammant's Blog: Ruby vs JavaScript for Web3.0
Pub debates on Ruby.
In a pub debate last night, I asked the remainder of the Chicago Ruby Users Group (chirb.org) whether they'd prefer Ruby to JavaScript in the browser as the language that supplements HTML to punch through the glass ceiling. The answer was a resounding no. JavaScript per se, and script.aculo.us in particular give you just about anything you need to supplement the feature limited HTML we all know and love.
The glass ceiling of HTML is worth restating for a second:
You have a combobox that lists colors in HTML, your customer asks for a small modification:
"Add an icon to the left of the name of the color in the color in question".
The issue is that plain HTML cannot do this. You must change technologies to JavaScript to do this. Hopefully from a library that someone else wrote. Writing it yourself would be very costly. Your customer expects a fairly cheap quote for the simple addition of the icon over the version that exists now. You really hope for that library to meet your customer's expectations. That and, you really hope that the new widget functions the same as the old one and runs on as many platforms.
One of the side effects of Test Driven Development and Refactoring in statically typed languages like Java is the ability to move code around a codebase using refactoring tools. When using Intellij IDEA, there are times when the tools built in are so good that you almost do not have to compile before you commit to SCM. There are hypothetical refactorings where we encounter a scenario similar to:
Validation of a field called 'foo' on the server side, is wrong, it needs to happen in the client instead, so that it happens long before the form containing foo is pushed to the server side. Functionality needs to move from server to client.
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? No - as we established. This time it was suggested that Rails does a perfect job of generating the client side validation of fields (incl JavaScript).
Push push push
I kept pushing for Ruby in browser as a 'need' for that community. Still the resistance was there.
The much maligned Obie remembered a company he was at before ThoughtWorks that had a web application that was very dynamic. It used an invisible Java applet and JavaScript to make the page behave like Web2.0. The same trick could be used, it was thought, with a Ruby plugin for a browser. Interesting.
A couple of years ago, I led a <stupid-but-fun> OSS effort called Thicky. It leveraged the lovely declarative syntax of GroovyMarkup and the page by page nature of Web1.0 to give a thick experience for people browsing the web. It stalled at a version a year from being usable by anyone. It was an interesting idea though.
Imagine a Ruby plugin for your fave browser that allows the same level of DOM and renderer interaction that JavaScript/JScript has presently.
You could have that HTML/Ruby future where Ruby was used instead of JavaScript to punch through the glass ceiling of HTML. It would of course be non-obvious to the user of the web application, beyond the installation of a plugin.
Alternatively, as with Thicky, you could have some solution where Ruby was the thing interpreted by the browser, and that script placed widgets on the screen. Imagine that that ruby plugin shipped with Gecko to browsers that did not have it already and made it available to the Ruby script for rendering and layout. The resulting page could be as easy on the eye and the best of the 'thin' web, and as functional as the best of the 'thick' world.
Bring on text/rhtml on the client side. One way or another.
You might need an aggressive permissions model for that environment or there would be whole new world of browser attacks opened up. Permissions being something that interests me from working on NanoContainer.
JavaScript and Ruby in competition?
The other thing I contentiously proposed was that JavaScript competes with Ruby. The gang was equally resolute : JavaScript is ECMA controlled, and thus will never have the features added matching those of Ruby.
Too much fun on a work night, and blogging again to appease the many that have requested it :-)
Jan 10, 2006.
Comment from Charles Lowell, also Jan 10 :
and in javascript
I particularly dislike always having to place the closing '})' after I pass a closure as an method argument in javascript. On the bright side. I suppose 'function' is better than lisp's 'lambda' in terms of descriptiveness, but ruby's version is the best for someone already fluent in dealing with closures.
Also, the choice to require the keyword 'var' in lexical variable declarations is bone-headed. That should be the default, and instead there should be a 'global' keyword to mark a variable as such.
That said, I'm still quite fond of javascript. I've been amazed what you can do given its solid, if not spartan principles.
In a pub debate last night, I asked the remainder of the Chicago Ruby Users Group (chirb.org) whether they'd prefer Ruby to JavaScript in the browser as the language that supplements HTML to punch through the glass ceiling. The answer was a resounding no. JavaScript per se, and script.aculo.us in particular give you just about anything you need to supplement the feature limited HTML we all know and love.
The glass ceiling of HTML is worth restating for a second:
You have a combobox that lists colors in HTML, your customer asks for a small modification:
"Add an icon to the left of the name of the color in the color in question".
The issue is that plain HTML cannot do this. You must change technologies to JavaScript to do this. Hopefully from a library that someone else wrote. Writing it yourself would be very costly. Your customer expects a fairly cheap quote for the simple addition of the icon over the version that exists now. You really hope for that library to meet your customer's expectations. That and, you really hope that the new widget functions the same as the old one and runs on as many platforms.
One of the side effects of Test Driven Development and Refactoring in statically typed languages like Java is the ability to move code around a codebase using refactoring tools. When using Intellij IDEA, there are times when the tools built in are so good that you almost do not have to compile before you commit to SCM. There are hypothetical refactorings where we encounter a scenario similar to:
Validation of a field called 'foo' on the server side, is wrong, it needs to happen in the client instead, so that it happens long before the form containing foo is pushed to the server side. Functionality needs to move from server to client.
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? No - as we established. This time it was suggested that Rails does a perfect job of generating the client side validation of fields (incl JavaScript).
Push push push
I kept pushing for Ruby in browser as a 'need' for that community. Still the resistance was there.
The much maligned Obie remembered a company he was at before ThoughtWorks that had a web application that was very dynamic. It used an invisible Java applet and JavaScript to make the page behave like Web2.0. The same trick could be used, it was thought, with a Ruby plugin for a browser. Interesting.
A couple of years ago, I led a <stupid-but-fun> OSS effort called Thicky. It leveraged the lovely declarative syntax of GroovyMarkup and the page by page nature of Web1.0 to give a thick experience for people browsing the web. It stalled at a version a year from being usable by anyone. It was an interesting idea though.
Imagine a Ruby plugin for your fave browser that allows the same level of DOM and renderer interaction that JavaScript/JScript has presently.
You could have that HTML/Ruby future where Ruby was used instead of JavaScript to punch through the glass ceiling of HTML. It would of course be non-obvious to the user of the web application, beyond the installation of a plugin.
Alternatively, as with Thicky, you could have some solution where Ruby was the thing interpreted by the browser, and that script placed widgets on the screen. Imagine that that ruby plugin shipped with Gecko to browsers that did not have it already and made it available to the Ruby script for rendering and layout. The resulting page could be as easy on the eye and the best of the 'thin' web, and as functional as the best of the 'thick' world.
Bring on text/rhtml on the client side. One way or another.
You might need an aggressive permissions model for that environment or there would be whole new world of browser attacks opened up. Permissions being something that interests me from working on NanoContainer.
JavaScript and Ruby in competition?
The other thing I contentiously proposed was that JavaScript competes with Ruby. The gang was equally resolute : JavaScript is ECMA controlled, and thus will never have the features added matching those of Ruby.
Too much fun on a work night, and blogging again to appease the many that have requested it :-)
Jan 10, 2006.
Comment from Charles Lowell, also Jan 10 :
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. It has great ideas like first-class closures, but lacks the syntax to use them gracefully. Read: the 'function' construct for anonymous functions is wonderful, but if you use it alot like I do, it does get tedious. Compare:
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. It has great ideas like first-class closures, but lacks the syntax to use them gracefully. Read: the 'function' construct for anonymous functions is wonderful, but if you use it alot like I do, it does get tedious. Compare:
#ruby
array = [1,2,3,4,5]
sum = array.inject(0) {|sum, element|
sum + element
}
array = [1,2,3,4,5]
sum = array.inject(0) {|sum, element|
sum + element
}
and in javascript
//note that Array.inject() is not part of normal javascript, I had to implement that myself.
var array = [1,2,3,4,5]
var sum = array.inject(0, function(sum, element) {
return sum + element
})
var array = [1,2,3,4,5]
var sum = array.inject(0, function(sum, element) {
return sum + element
})
I particularly dislike always having to place the closing '})' after I pass a closure as an method argument in javascript. On the bright side. I suppose 'function' is better than lisp's 'lambda' in terms of descriptiveness, but ruby's version is the best for someone already fluent in dealing with closures.
Also, the choice to require the keyword 'var' in lexical variable declarations is bone-headed. That should be the default, and instead there should be a 'global' keyword to mark a variable as such.
That said, I'm still quite fond of javascript. I've been amazed what you can do given its solid, if not spartan principles.