Im using it for an internal project. There is an associated `vienna` gem, that is for building rich web apps (think sproutcore, cappuccino). It is not open source yet, but will be once the project its been written for is finished.
Looks like a cool project, but it would be nice if the docs were a little more complete or there was a try it out feature like on http://jashkenas.github.com/coffee-script/
I have been using a similar project (Red) for a year in production.
Here is why we wanted to use it:
- Development speed (ruby can be typed so much faster and has a class system)
- Packaging system (we want one minified js-file)
- Code reuse (we use Ruby in the backend)
Here is why we stopped using it in favour of native JS:
- Slow runtime (try to read some big JSON in your favourite js-ruby, we had time diffs of 20secs to 0.2secs native js speed)
- Debugging (this is the most annoying thing, which you will not realize in the beginning)
- Development speed (recompiling time increases the more accurate the ruby implementation gets - my fork actually used multiple cpu cores)
- Red was immature (had my own totally rewritten fork going...)
I still love projects like this, but the mentioned problems will not all go away any time soon (a few of them might).
By the way, CoffeeScript shares some of these downsides, but is far less of a pain, because the whole language was designed with JS in mind (fast compilation, fast runtime etc.).
Actually, as stated on Coffescript's wiki[1], there are many other implementations of ruby on JS:
* HotRuby Runs opcode, compiled by YARV on Ruby inside a web browser or in Flash.
* rb2js Converts Ruby to JavaScript.
* Red Writes like Ruby and runs like JavaScript
* Quby Used for game coding site, not open source.
* Opal Ruby to Javascript compiler.
It seems interesting that nobody has tried to use Rubinius (which tries to implement Ruby in Ruby) to leverage any of these implementations, possibly reusing a JIT mechanism.
In cases like this it means that the language was built to compile down into the other language. So you can write ruby code andnthat spits out JavaScript for thte browser to read.
13 comments
[ 3.0 ms ] story [ 32.1 ms ] threadCheck out https://github.com/adambeynon/opal/tree/master/examples/brow...
Here is why we wanted to use it:
- Development speed (ruby can be typed so much faster and has a class system)
- Packaging system (we want one minified js-file)
- Code reuse (we use Ruby in the backend)
Here is why we stopped using it in favour of native JS:
- Slow runtime (try to read some big JSON in your favourite js-ruby, we had time diffs of 20secs to 0.2secs native js speed)
- Debugging (this is the most annoying thing, which you will not realize in the beginning)
- Development speed (recompiling time increases the more accurate the ruby implementation gets - my fork actually used multiple cpu cores)
- Red was immature (had my own totally rewritten fork going...)
I still love projects like this, but the mentioned problems will not all go away any time soon (a few of them might).
By the way, CoffeeScript shares some of these downsides, but is far less of a pain, because the whole language was designed with JS in mind (fast compilation, fast runtime etc.).
[1] https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
Same thing with coffee script / objective-j