#297 Running JavaScript in Ruby pro

Great screencast.

It would be cool if we could use helpers from Rails (number_to_currency etc.) in JS :( bu t that is not possible.

I think this a bit of a stretch... while there might be some situations when this kind of mojo would be helpful I don't it should be normal practice. In fact it breaks the MVC somewhat. What I normally do is one of two things: either app is fully JS–based and logic is processed via JS while rails acts as server side model or use ajax to fetch pre–processed data and only display them via js code.

Re: memory leaks, it seems like it would be easy to attach a counter to the JS context and say, every 1000 uses, go ahead and dump the existing context and re-build a new one. Inelegant, but effective! Just wanted to throw that idea out there.

what's the benefit to using therubyracer (V8) vs therubyrhino (mozilla)?

therubyracer is api compatible with therubyrhino but doesn't require python to be installed to compile.

Just a heads up, you don't need to do this:

@Product = Product

For the Product class to be globally available. You can combine that into the actual definition of the class, like such:

class @Product
  # etc...

Very nice stuff Ryan !
You always are a precursor ;)

But what I'm asking is : to push further, why not using node.js and being able to transparently share code between the client and the server ?

Don't make me wrong, I love ruby and want to continue to work with rails !

Thanks for the great screencast!

When it turns to such things as DRY concept between Server <-> Client, I think about DSLs. Ruby is a great language for embedded DSLs, so why not to write a new DSL to write (for example) validation code with and then generate and execute from that DSL-code:
- Ruby no the server side
- JS on the client side

This DSL could be exandable by rails apps to allow any complexy operation. On the other hand, such DSL could also provide the natural limitations to users. For example, you can't ready access dom attributes or data base from such "DRY" code.

What are you think?

Hmmm, some good points made in these comments. And I have to say I'm leaning towards Sergey Kuleshov's comment. This is a very cool screencast, but I'm not sure I'd go this far in a production project.

I like that you're showing us Coffeescript usage too Ryan, it's lowering the barrier for me, but I've got to say, I still prefer straight Javascript. I still find Coffeescript very hard to read. Ultimately, I think I'd love to be able to write my Javascript in Ruby.

The similarity of Ruby's new hash syntax is bringing the two closer, and this is something I adopted only this week. Yeah, I know... slow on the uptake.

Hi,

Probably a newbie question, but I want to be sure...Can I use ExecJS to execute JS code on the client side?
Thanks!

This is the first time I've ever seen "caching" implemented by storing something in Thread.current...is this somewhat of a standard practice? Anyone have any links to more explanation of this technique?

Wouldn't it make more sense to create a $JsProduct class object in an initializer and then call new on $JsProduct in the for_mustache method?

config/initializers/js_product.rb

coffee = File.read(Rails.root.join("app/assets/javascripts/product.js.coffee"))
javascript = CoffeeScript.compile(coffee)
c = V8::Context.new
c.eval(javascript)
$JsProduct = c.eval("Product")

models/product.rb

def for_mustache
  $JsProduct.new(to_json)
end