一年前我做了一个关于这个主题的演讲。我第一次关注这个技术是因为 @dhh发布的他们在 37signals使用的一些观点。我注意到他们 在模板视图里</span>如何使用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调用。

首先，一个例子

class PostsController < ApplicationController    def index      @posts = Post.all    end      def show      @post = Post.find params[:id].to_i      respond_to do |format|        format.js        format.html      end    end      def create      #.. Create a post      respond_to do |format|        format.js        format.html      end    end  end

<!-- app/views/index.html.erb -->  <ul class="posts">    <%= @posts.each do |post| %>      <%= render_link_to_post(post) %>    <% end %>  </ul>

# app/views/create.js.erb  (function() {    var $post = $("<%= j render_link_to_post(@post) %>")    $post.hide().prependTo($("ul.posts")).fadeIn()  })()

# app/views/show.js.erb  (function() {    var $post = $("<%= j render("overview", post: @post) %>")    $post.dialog("open")  })()

<!-- app/views/show.html.erb -->  <div class="title">    <%= @post.title %>  </div>  <div class="body">    <%= @post.body %>  </div>

#helper.rb  def render_link_to_post(post)    link_to post.title, post_path(post), remote: true  end

在这个例子中，当有人点击链接，它将会调用/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个不同的地方加载：

1. 由标签链接加载JavaScript。在页面加载时加载，运行时不能定制，JavaScript可以被预编译；
2. 作为用户页面动作的响应加载。

对服务内容能更好的控制是这种方式的优点。如果你感觉解析代码较多时慢，你可以一些请求时的负载抽取到标签链接中加载。

当需要时加载需要的

由于网页在服务器端的渲染，所以响应最小化时你有很多可选的库，也许你可以试试jQuery、Zepto或其他什么的，但记住：JavaScript几乎从来（我不知道是不是每个都是）不在加载时渲染页面，加载完后才开始。

看看上面的例子。create.js.erb上有个问题，我可以用很好的功能和其他好东西来包装它，但如果人们从不发布post这有什么意义呢。

这需要你维持一个平衡。当有有些东西大量使用是（每用户每页使用超过一次），像你其他库一样用标签来加载它吧，其他的当HTML动作触发时再加载吧。

可重复的动作(调试目的)

你是否遇到过这种情况，当你调试应用的时候3~4个不同的动作都提示你的javascript代码里有bug？因为响应是独立的JavaScript代码，你只能将响应粘贴到控制台一步步捕捉异常。

我做了什么呢，我拿掉了挡在我和我正在使用变量间的障碍，这样，在控制台了我可以将bug缩小到变量层面。

清晰

客户端的JavaScript通常与通知或事件搭配使用，触发这些事件、收到服务器更新，这一切瞬间就绪。通常瞬间见效的事通常难以追踪。

当响应是JavaScript代码时结果就很容易理解了。看看上面的例子，我详细你能明白这两个Ajax响应的预期行为。

就是这样

这是我的选择，你可也可以有自己的选择。我希望你喜欢这篇文章且有了自己尝试一下的冲动。 

如果你实现了，在推ter给我留言告诉我它是如何运行的！