The major difference is execution context. The javascript and ruby get executed on completely different systems, so running Ruby (on the server) to generate code that is executed on a different machine (the client) is a major complication, and when the abstraction gets leaky, all hell breaks loose. The result becomes incomprehensible and unmaintainable, though not impossible to get working. I think the consensus of Rails devs who have used and abused RJS extensively (as I have) are recognizing its major shortcomings and have embraced Unobtrustive javascript as the preferred approach.
That said, I don't mind the idea of using Ruby to generate the javascript itself. Red/Redshift (codingred.com) looks like a promising project. It's a lot like SASS where it takes your .red files (written in ruby) and preprocesses them to javascript. It only happens once though, and it basically a way to write non dynamic javascript using Ruby. Still, its a risky business to get into, and it tends to be much safer just writing javascript code in javascript. On Jan 24, 3:32 pm, Phlip <[email protected]> wrote: > Jacques Crocker wrote: > > On an unrelated note, I saw some your previous posts reference testing > > RJS methods. RJS enabled Rails apps are very difficult to port to Merb > > since there is currently no javascript generating Ruby libraries > > currently for Merb. Would be cool if someone wrote RJS as a plugin to > > Merb (maybe they have?) > > That sounds like more than cool; the Rails 3 + Merb marriage would appear to > require it. Whatever your opinion of RJS abuse, it will continue! > > > but that might not be high priority on > > > developers minds because RJS is a pretty poor web development > > practice. I got on the bandwagon early when it came out in Rails only > > to realize all too well the major drawbacks of generating javascript > > code on the server to be run on the client side. But thats a topic for > > another thread. > > I always figured the relationship between the Ruby DSLs (ActiveRecord, RJS, > content_tag) and their target languages (SQL, JS, HTML) was the same as the > relationship between early C and Assembler. You write the C to avoid writing > the > Assembler, but it's always there, under the hood, when you need it. > > The good news is our platforms, such as all the web browsers out there, must > now > start permitting better DSLs and better code generation. The comparison to C > and > Assembler is that modern CPUs are now tuned to work with C compiler > technology, > not the other way around. > > -- > Phlip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
