一年前我做了一个关于这个主题的演讲。我第一次关注这个技术是因为
@dhh发布的他们在 37signals使用的一些观点。我注意到他们 在模板视图里如何使用JavaScript，动态生成JavaScript这是它的关注点，这引起了我的思考。
与之前我们在前端加载全部javascript相比，为什么我们不加载最少量的JavaScript然后在用户界面需要的时候再加载额外的JavaScript代码呢？
我把这称为响应式的JavaScript，你听说过pjax这个 术语，或者 unobtrusive JavaScript，等等。目的是后端的JavaScript按前端动作加载。不管是GET、POST、DELETE等待，只要请求是ajax，响应将会是JavaScript而不是JSON。
你使用的一些产品中的一些实例或许已经使用这个 概念了。BCX、GitHub、Airbnb都以不同方式使用了这个概念。这一概念的问题在于它不绑定任何的库或框架，你必须使用目前的工具来它工作。庆幸，现在已经有了一个JavaScript库可以帮助你开始。jQuery-UJS可以让你添加 remote=”true” 到任何链接，这些链接会自动转换成一个Ajax调用。
首先，一个例子
01 |
class PostsController < ApplicationController |
07 |
@post = Post.find params[:id].to_i |
08 |
respond_to do |format| |
16 |
respond_to do |format| |
1 |
<!-- app/views/index.html.erb --> |
3 |
<%= @posts.each do |post| %> |
4 |
<%= render_link_to_post(post) %> |
1 |
# app/views/create.js.erb |
3 |
var $post = $("<%= j render_link_to_post(@post) %>") |
4 |
$post.hide().prependTo($("ul.posts")).fadeIn() |
1 |
# app/views/show.js.erb |
3 |
var $post = $("<%= j render("overview", post: @post) %>") |
1 |
<!-- app/views/show.html.erb --> |
2 |
def render_link_to_post(post) |
3 |
link_to post.title, post_path(post), remote: true |
在这个例子中，当有人点击链接，它将会调用/posts/:id。如果请求是AJAX，它将调用show.js.erb，执行模板里的代码。如果不是的话，它将调用show.html.erb。还有一个叫created.js.erb模板，当你通过Ajax表单创建一个资源时将被调用。表单被清理的尽可能简单。
URL帮你定位到bug
假设你点击链接时有一个bug，通过使用这种技术，你可以通过查看URL追溯起源。
举例：posts/:id与与位于app/views/posts/show.js.erb的JS模板相关联。
正如你在处理HTML视图时所期望的一样。
web页面有生命期
回顾一下上面的例子。当你用Ajax表单发布一条post，按预设列表将生成一个与该post对应的链接。看一下请求的方法：它和你调用/posts时相同，这不是一种偶然。当你使用这种方法时会试图避免代码重复，ajax除了不最终生成页面外与正常请求使用相同的组件。
这意味着，当你发布一个新post后，如果你刷新页面，将会显示相同的文章列表，因为它们使用了相同的机制。
复用相同的视图逻辑
这是一个以前的扩展。既然在服务器端已经生成了HTML，你可能会在视图里看到很多重复代码，使用助手类或修饰器来简化代码将不会是件难事。
因为所有映射都来自从同一个地方，HTML的修改也可以在同一个地方完成。比如，如果我想要将列表中的链接替换成一个更具描述性的，我可以修改render_link_to_post（一个坏的函数名，原谅我）的实施细则以适应变化。
JavaScript在动作间的传递 & 页面加载优化
现在，你的JavaScript在2个不同的地方加载：
由标签链接加载JavaScript。在页面加载时加载，运行时不能定制，JavaScript可以被预编译；
作为用户页面动作的响应加载。
对服务内容能更好的控制是这种方式的优点。如果你感觉解析代码较多时慢，你可以一些请求时的负载抽取到标签链接中加载。
当需要时加载需要的
由于网页在服务器端的渲染，所以响应最小化时你有很多可选的库，也许你可以试试jQuery、Zepto或其他什么的，但记住：JavaScript几乎从来（我不知道是不是每个都是）不在加载时渲染页面，加载完后才开始。
看看上面的例子。create.js.erb上有个问题，我可以用很好的功能和其他好东西来包装它，但如果人们从不发布post这有什么意义呢。
这需要你维持一个平衡。当有有些东西大量使用是（每用户每页使用超过一次），像你其他库一样用标签来加载它吧，其他的当HTML动作触发时再加载吧。
可重复的动作(调试目的)
你是否遇到过这种情况，当你调试应用的时候3~4个不同的动作都提示你的javascript代码里有bug？因为响应是独立的JavaScript代码，你只能将响应粘贴到控制台一步步捕捉异常。
我做了什么呢，我拿掉了挡在我和我正在使用变量间的障碍，这样，在控制台了我可以将bug缩小到变量层面。
清晰
客户端的JavaScript通常与通知或事件搭配使用，触发这些事件、收到服务器更新，这一切瞬间就绪。通常瞬间见效的事通常难以追踪。
当响应是JavaScript代码时结果就很容易理解了。看看上面的例子，我详细你能明白这两个Ajax响应的预期行为。
就是这样
这是我的选择，你可也可以有自己的选择。我希望你喜欢这篇文章且有了自己尝试一下的冲动。
如果你实现了，在twitter给我留言告诉我它是如何运行的！