RJS是邪恶的吗?为什么?

时间:2009-11-17 17:34:11

标签: javascript ruby-on-rails rjs

我听到一群铁路开发人员说RJS是邪恶的。我从来没有用过它,因为我总是设法用经典的javascript或jquery做我想做的事所以我没注意。现在我进入了一些遗留代码,到处都有RJS。

所以......这是真的吗?使用RJS有什么缺点/优点?

7 个答案:

答案 0 :(得分:30)

让我们先讨论一下RJS是什么,然后才知道它是不是邪恶。

RJS将相同级别的抽象应用于ActiveRecord为SQL提供的高功能Javascript库。然而,Javascript库的RJS覆盖范围远不及ActiveRecord对SQL适配器的覆盖范围那么完整。

Rails只提供对Prototype / Script.aculo.us的RJS支持。但是,有一些插件可用或正在开发中以支持其他Javascript库。例如,JRails重写基于Prototype的助手以使用jQuery。类似的插件存在于mootools和可能的Dojo。

认为RJS是邪恶的人通常是那些不熟悉它生成Prototype代码的人,或者那些觉得他们可以用原始Javascript更容易完成事情的人。

RJS并不完美,就像ActiveRecord并不完美一样,您经常需要编写原始Javascript或SQL来完成工作。再次像ActiveRecord一样,使用高级选项越舒服,无需编写原始代码即可完成的工作越多。

关于RJS的一个奇妙之处在于它们本质上是视图,它们产生Javascript。可以很容易地将RJS提取为可以根据需要包含的部分,作为对控制器的响应或作为页面中包含的自定义Javascript函数的一部分。这使得代码更加干燥,从而可以简化维护。

我个人经常使用RJS。我发现它是一次触摸大量DOM元素的完美方式。它带来了双重奖励,允许我创建AJAX丰富的网站,而无需编写太多的Javascript。然后我再讨厌写Javascript。

答案 1 :(得分:5)

考虑到我在我的Rails项目中用JQuery替换我的底层Prototype库,我发现RJS非常有用。现在,有时候将JavaScript传回服务器并不是主流,这可能会很痛苦。

但是,我发现RJS一般没有问题。我唯一的抱怨是我通常必须将RJS和普通的旧Javascript混合到我的.rjs文件中,所以它有点毫无意义。但它确实为你提供了一个干净的地方/方式来处理你的Javascript效果和AJAX调用,所以我认为这是一个“放置代码的标准位置”,它非常好。

答案 2 :(得分:3)

我不知道我是否会说邪恶,但RJS(或生成JS的任何服务器端语言)都不是我的首选。我更喜欢手工编写JS。使用jQuery,我真的很喜欢编写JS并将我的JS保存在application.js中,感觉很干净。

扩展一点...我认为RJS是一种不必要的抽象。我想知道JavaScript和jQuery。我想知道如何操作DOM以及如何进行AJAX调用。利用我的JS / jQuery知识,我可以轻松地转移到another framework,并且不知道框架是否会为我处理我的JS。

答案 3 :(得分:1)

RJS很不错,主要是因为它很容易集成到Rails项目中。为了简化操作并保持较低的文件数,您可以将其嵌入到控制器中,并且它具有许多来自原型/ scriptaculous库的易于使用的帮助程序。它感觉更像Ruby。

它确实意味着它与普通的Rails代码没有完全分开,因为它很快就会与其他代码混合在一起。它还需要通过原型和scriptaculous js文件包含更多的外部库。

一些jQuery的东西很干净。语法非常疯狂,但这意味着你可以将你的js完全从你的页面/控制器(不显眼的js)中拉出来,这是一种更清洁/分隔的方式。

更重要的是,jQuery看起来像javascript。所以你没有得到javascript和Ruby代码的奇怪组合。我喜欢Ruby。我不喜欢Javascript。但我更喜欢两者的混合。如果你了解JS,你会觉得它很熟悉。

Ryan Bates有关于将RJS转换为jQuery的截屏视频。可能会让你很好地理解两个句法上的区别:http://railscasts.com/episodes/136-jquery

答案 4 :(得分:1)

如果您不熟悉JS(或像Prototype这样的框架),但您需要AJAX功能 - RJS是最好的方法。使用RJS的另一个好处是速度。轻松快速地编写RJS代码。

之前我在所有Rails项目中都使用过RJS。现在我对Prototype(和jQuery)更加熟悉了,这就是我现在编写JS代码的原因。我需要这个,因为有很多RJS的控制器失去了它的生产力。将RJS代码移到JS中是扩展控制器的第一步。

没有人可以绝对地告诉你,最好的方法是什么 - 使用RJS与否。每个人都应该选择自己的方式。

例如,我更喜欢在我的应用程序的管理部分(不需要扩展任何东西)中使用RJS,并为前端部分编写JS。

答案 5 :(得分:1)

RJS不是“邪恶的”,但我认为它的问题是双重的:

  1. 使用RJS进行不显眼的JavaScript很难(不可能?)如果您正在编写一个Javascript密集的应用程序并且具有大量逻辑,并且该逻辑发生了更改,那么您将不得不更改相当数量的文件而不是一个。此外,这是个人偏好,看到带有压缩Javascript的标签遍布它是相当丑陋的。

  2. RJS抽象出Javascript,这会导致对语言的无知。 RJS背后的想法是让开发人员能够使用一种语言编写Web应用程序的所有内容(除了设计人员可能会解决的HTML和CSS之外):Ruby,但在实践中,这一点也不尽相同通过拖放控件或使用大量繁重的代码生成向导来创建ASP.NET应用程序是可能的,但不建议这样做。如果您只需要一个简单的解决方案来解决Ajax问题,那么RJS就可以正常工作。

  3. 当您刚开始使用Rails时,RJS是一个很好的工具,需要一些谨慎使用的“快速而肮脏”的Ajax效果(例如,在同一页面上淡入的Blog的规范评论)。一旦你开始需要大量的Javascript使用,那么RJS就变得更加负有责任,因为它可以保护开发人员免受他们真正应该尝试理解的问题。

答案 6 :(得分:0)

RJS只是RHTML的JavaScript等价物(现在称为html.erb)。它是一个执行嵌入式Ruby的模板,并将JavaScript返回给浏览器以更新页面。这允许您对AJAX应用程序中服务器端操作的结果具有更好的控制权。实际上,RJS调用的结果由浏览器中的JavaScript解释器评估。将此与非RJS AJAX应用程序进行对比,其中服务器返回通过异步请求的回调插入到页面中的HTML。

“邪恶”部分是许多人对“评估”感到不舒服,但我认为这也可能是某种混乱的结果。

这里的许多回复似乎都集中在JavaScript,Prototype和Scriptaculous Helpers上,这些助手经常被使用,但不是必需的,作为RJS模板的一部分。我确实广泛使用这些帮助程序,因为它们更好地使用模板中的Ruby代码,但它们不是RJS的必要部分。