所谓的节省那点带宽，根本就微不足道，带来的不便，太多了，卡到死
用户体验太烂了，给所有 body 内的元素自动添加事件，这个做法太耗资源了，有种胡子眉毛一把抓的感觉。不管用到用不到，把 body 内的所有元素过一遍，这得多大的计算量啊
哪里把所有元素过一遍了？
我建议是能看懂 turbolinks 源码的尝试用，不想看或者看不懂的不要用。
就不明白了，技术细节还没有搞懂呢吧就在这里喷屎……当年 AJAX 出世的时候岂不也是一堆屎？或许论及影响力和重要性尚不能相提并论，但毕竟是进步，是创造。人类追求进步的信念和动作，有成功也有失败，也从来没有百分之百的完美，但无论如何，尽享别人创造的人也没有丝毫立场可以大放厥词吧？
客观的说，turbolink 在客户端的实际体验中，页面刷新的闪烁感有所降低，但与 pjax 相比有相当明显的差距，特别是在稍低端一点的机器上，turbolink 的体验相当接近传统方式的刷新闪烁感。
从原理上，turbolink 既不节约带宽也不节约服务器资源（注意传统方式中 css 和 js 在客户端都是有缓存的），它真正节约的是 css 和 javascript 在客户端的本地加载时间和执行时间。在传统方式中，css 和 js 虽然都有缓存，但浏览器从本地缓存中取出来并执行它也是需要时间的，而 turbolink 的工作方式主要就是节约了这个时间。
我曾用过 rack-pjax，简单的试用了一下 turbolink 之后，马上认为眉毛胡子一把抓的 turbolink 绝对是对 pjax 的一种错误进化方式，很有可能 Rails 4 的绝大部分的使用者都会毫不犹豫的删掉 turbolink 那一行的，而我自己正是这么做的。
pjax 相比 turbolink 最大的优势在于简单性和灵活性，它对页面事件没有侵入，js 代码该怎么写就怎么写，用不用 pjax 与自己的 js 代码一点关系都没有。第二个优势在于 pjax 更接近真实的需求：我点页面上的某处链接，页面上另一处发生改变，这种更类似于原生程序的体验才是需要的。而不是 turbolink 这种：我点页面上任何一处链接，整个页面无闪烁地发生改变，这种是真实的需求吗？至少对于我来讲不是。因为如果整个页面的内容都变了，无论如何都是有闪烁感的，不信你们自己试试。
虽然我认为 turbolink 本质上就是一砣屎，但是 pjax 相关的 gem 已经不更新了，但我想起了 DHH 曾经的疑问，pjax 很好啊，为什么大家不用它呢？他可能以为是因为 pjax 的编码负担太重了，或者可能以为是没有集成进 Rails 核心的缘故，所以他又制造了 turbolink 这个轮子，还整成标配的。
但是很有可能，DHH 错了，大家不用 pjax 的原因不是它不够好，也不是因为它太复杂，而是万恶的 IE：我 TMD 百分之九十五的客户都用 IE，上 pjax 还有意义吗？
虽然 Turbolinks 很好用（至少我是这么认为的），但 Turbolinks 的方向错了，未来都是前端 MVC 的天下了，连 Routing 都在前端实现，Js 和 CSS 都只加载一次，有 Asset Pipline 就够了。
#12 楼 @xhj6 无意在这里讨论什么技术细节，各种方面的评论网上到处都是。我说的是那种不断追求和进取的精神和态度（尽管也有可能是错的，谁能保证永远是对的？）哪一种技术没有被喷过？它们之中有死的，也有活的，但无论如何人们记住的是什么？是喷？还是……？
无论怎么喷，DHH 已经成就了自己，虽然不代表他永远不会犯错，但更不能证明只要喷他（以及他代表那种进取和追求的精神）就能让自己更高明。讨论技术细节怎么说不可以，一定要用某些词才能证明自己的分量不成？
据说艾迪生在确定灯丝的材料之前尝试了上千次？如果在当今这个信息发达的时代，那他岂不是也需要被喷一千次？
我们应该追求被别人“喷”，而不是去“喷”别人，因为在旁人眼里，二者高下立见。
#10 楼 @as181920 其实这问题挺简单的，turbolink 是否干扰你开发了？你是否真的特别赶时间？这俩问题回答了，就知道用不用了。
在我看来，Turbolinks 是一个阶段性的折中方案，或许 DHH 的力推让人觉得他似乎是把“未来的赌注”全压在这上面了——也许——我个人不相信他会这么短视。
Turbolinks 想要在目前这个阶段利用 server-side 的能力来弥补 pjax 在应对跨浏览器兼容性问题上的困境——这不是 pjax 的错误，也并非是想要取 pjax 而代之。因为 pjax 是 client-side 技术，这两者之间原本就没有一较高下的必要。
鉴于使用 Rails 的开发者数量庞大，而他们之中能够轻松掌控前端的数量却又不多——要知道，Javascript 有大部分的工作都用在和浏览器斗争上了——所以 Turbolinks 对于大多数开发者来说是一个代价相对较低的过渡方案。
然而使用 Turbolinks 的确会有一些 gotcha 需要开发者去注意，这也是 Rails 历来的传统和理念：注意一些“约定”。约定未必会成为标准，但却是向标准前进的一步努力，这种过程也是开发届的习俗。比如说 web 标准历经“磨难”的过程，最常见的像 vendor prefix，不也一样被开发者们一边用一边骂？但事实却是，不这么做就不能取得进展。很多东西你指望一步到位，那是一种理想，而不是现实。
如果 pjax 已经足够健壮了，DHH 吃饱了撑的非要给自己找不痛快？事实上，作为一个后端的开发框架，Rails 算是最关注前端，对前端最友好的一个了吧？也许它的一些决定并不能讨好所有的人，但是它让关注前端的后端工程师越来越多，帮助这些后端工程师更少障碍的了解和掌握前端技术的努力却远远要比”讨好所有人“更有价值的多！
世人的浅见啊，少一些浮躁，多一些探索，该多好？不禁想起前日看的小说了一句话：“众口悠悠之中，江郎或有才尽之时；不过在嘲笑于他之前，众生之中又有多少‘江郎’横空出世？”
Turbolinks 当然不算完美，但说它是“屎”也未免太自大了，就算它是“屎”那它也是培育技术和思想进步的“肥料”，总要比随地乱喷的那种有价值的多。
最后，喜欢关注细节的，不妨看看 Yehuda 的一篇积极中肯的评论吧：https://plus.google.com/106300407679257154689/posts/A65agXRynUn
#17 楼 @nightire 基本上我完全同意你本楼的观点，但你说的和我不是一回事，你在意的是一种态度价值观，而我在评价 Turbolinks 本身。
事实上，就我自己而言，除了拉肚子，一般不喷某种东西。但是，我仍然认为这种表达方式如果建立在自己的真实感受的基础上，喷一喷也无伤大雅。就进步而言，反馈是必需的，特别是负面的反馈。不是每一个人都有被喷的能力，就像不是每一个都能设计出 iOS 7 一样，但那并不妨碍人们表达对 iOS 7 的真实感受，然后，iOS 7 的确也在被喷中前行。
我的观点是，无论是无内容的喷，还是无内容的反对喷，都是无意义的，都是噪音。
就技术能力而言，@nightire 远胜于我，但 @nightire 你并没有回应对等的东西给我，很是让我失望，这好比我给你谈待遇，你却给我谈理想，这不是耍流氓吗？
下面我们继续谈一下待遇的问题：
我看了 @nightire 最后推荐的评论，他说使用 Turbolinks 之前要想清楚这三点：
• Your JavaScript is designed to be long-lived across many different
HTML pages without a refresh
这一点我的想法是，Turbolinks 过于理想化了，没有解决真实的需求。我再次重申下前文的观点：比方说，帖子列表页面 与 帖子显示页面，css 及 js 都大不相同，难道不是重新加载一下的恰当时机吗？真实的应用都是复杂的应用，极有可能是由几个或十几个而不是由一个页面应用组成的，在不同的页面中，你让毫不相干的 js 存活，有什么意义？还是用这个简单的例子，我认为，在帖子列表页面中点分页链接，页面不应该刷新，在帖子显示页面中回复评论点喜欢，页面也不应该刷新，而从列表页面跳转到显示页面，刷新一下 css 和 js 是非常必要的（你要加载非常多新的东西）。
另一方面，如果你的应用的确是一个单页应用，那么，Turbolinks 也不是正确的选择，前端 MVC 才是。
• Your refresh handlers are idempotent. Don't register event handlers
or other bindings in a refresh handler unless you reliably tear them down.
• You audit all third-party code that you use to make sure that they do not
rely on DOM Ready events, or if they do, that they DOM Ready events are
idempotent. If you don't feel comfortable auditing and cleaning up
third-party code, don't use any.
这两点，足以把绝大多数人吓退了吧，我最喜欢 $ -> 了，你不让我用，我怎么活？什么！？第三方库也不能用？？你知道多少第三方库依赖 DOM Ready 吗？？？
综上所述，Turbolinks 在现阶段，并不值得使用。
再次谢谢 @nightire ，请你明确回应一下我要涨工资的要求，谢谢。
#12 楼 @xhj6 我不想推荐别人用或不用 Turbolinks，不过我要指出你理解有误，Omakase Stack 中局部更新或者其他写操作用的是 UJS。
Turbolinks 就是个链接加速器，什么是链接？例如第一页到第二页，列表页到详细页。很多人都把它当作万能的，拿它和 jQuery 比，拿它和 Angularjs 比，然后说它怎么没有解决所有问题。那是当然的，Turbolinks 不会解决所有问题，它只是个加速器。第三方库的问题，说得好像前端 MVC 就没有 DOM Ready 问题一样，任何单页应用都有这个问题。
Assets Pipeline + Turbolinks + UJS 是 Omakase Stack 的一种方案，当然可以选择另一些前端方案，而只让 Rails 提供 API，或者干脆不用 Rails，这都是解决问题的不同方案，每个人有选择的权利。我依然不认同因为不喜欢一个方案就要喷，并且在那个字后面接着 @ 我的 id，我不知道你是不是故意让我不舒服的，我不想再展开。
讨论到这儿我想就没有必要继续了，我想给楼上的建议是，试着学会包容不愉快的东西能让你的心情更加愉快，另外，不要把任何东西神圣化。
绝大多数开发者，并不会把什么 Omakase 或 Prime 技术栈当成法律，也不可能认为哪个东西就是万能的，这样只会狭隘你的思维。我想讨论的是，这个东西所要解决的需求是什么？这个需求需不需要解决？它付出的代价是合理的吗？但一直没有得到正面回应。
另外，请不要以自己的思维方式来理解别人，尊重每一个人的不同。Rails 中，有好用的部分，也有不好用的部分，选不选择与喜不喜欢是两回事，喜不喜欢与评不评价也是两回事，选择、好恶、评价等等都是权利，都值得尊重，为什么要我三选一，二选一？
Anyway, take it easy, thanks.
这个东西所要解决的需求是什么？这个需求需不需要解决？它付出的代价是合理的吗？
我还以为你自己能提炼出来。这里再总结一次，解决静态文件重复解析的问题；取决于项目需求；取决于自己判断，对于那些 js 写得乱七八糟的项目，付出的代价非常巨大。我已经用上了，觉得挺有意思，如果有人对这个东西有技术上的疑问，那么我会分享我的经验。接下来我会试试另一个思路，试着用前端框架，为什么会觉得我把东西神圣化？
我让你包容些，不要喷，你要我包容你喷。
呵呵。
实际上我年龄比大很多，这么说吧，小孩子会顽皮，大人会呵斥，老人会呵呵——我叫你要包容我喷，充分说明我已经老了。
解决静态文件重复解析的问题，是的，我前文也是说的这个意思，只是用词更通俗一些，我也还很啰嗦的表达了我的疑问：静态文件需不需要被适当地多次解析？
如果适当的多次解析是必要的，Turbolinks 就是在解决一个虚假的问题。而正如 Turbolinks 名称暗示的，你所说的链接加速这个效果，Chrome 等浏览器的预加载功能已经在消灭这个需求了，从这点来看 Turbolinks 也似乎是在解决一个即将消失的问题。
我觉得你把技术神圣化的理解来源于你说 Omakase Stack 是如何做的，这让我觉得你有点死板，不管是 Turbolinks 或是 pjax，它们都离不开 UJS，UJS 有被讨论的必要吗？
最后总结陈词：我纯个人意见认为 Turbolinks 不值得深究，非要我选择，我宁愿选择 pjax。但是，更可能的是：屎味巧克力，和巧克力味的屎，我会吃哪一个呢？我两个都不吃不可以么，就像你说的，下一个项目，我也会就尝试纯前端方案，也许那才是未来正确的方向，对不对？
唉……扯到年龄就没意思了。
Assets Pipeline + Turbolinks + UJS 是 Omakase Stack 的一种方案，当然可以选择另一些前端方案，而只让 Rails 提供 API，或者干脆不用 Rails，这都是解决问题的不同方案，每个人有选择的权利。
我没说 Omakase 永远是对的，给人带高帽的讨论真是非常不愉快。我尝试理解 Omakase 的方案，理解它的好处和坏处，并且解释为什么有的人用法不对。自己看好的技术一定要大卖，自己不看好的技术一定要大暴死？我可没有这么偏激的看法，积累不同的经验，有助于我写出更好的程序。
如果有技术性问题可以再讨论，我要说的都差不多了。
#19 楼 @xhj6 因为我一开始说的就是态度，是你在回避态度的问题。从头到尾看下来，我从未说过 Turbolinks 不能批评，我说的是什么有点文化的人都能明白。
你强调 Turbolinks 不能解决你的需求，付出的代价让你觉得不值得。那么我认为对你而言可能是合理的，然而你的需求能代表所有人的需求吗？Rails 每前进一步都只是为了解决你，或者以你为代表的一群人的需求吗？
看起来你也应该是比较了解前端的人了，推此及彼，请问 verdor prefix 这样的东西解决了怎样的问题？满足了怎样的需求？付出了怎样的代价？
如果把 pjax 看做是像 web 标准这样的一个目标，Turbolinks 就好比是 verdor prefix 这样的过渡方案，它完美吗？绝不！它能解决问题吗？可以！它有代价吗？不小！它能满足需求吗？It depends。
它是屎吗？
$ -> 这样的语法 Turbolinks 不让你用？你是认真的吗？你确定？
在现实中我也只会考虑给态度 ok 的人“涨工资”，讨论技术细节也一定会在态度 ok 的前提和环境下进行，否则我宁可把人拽出去吃个饭谈谈心先。
有这样四种人：
- 有德有才——绝对加钱涨工资，不用你开口要；
- 有德无才——留下没有坏处，涨不涨工资看进步；
- 无德无才——淘汰，没说的；
- 无德有才——这是最可怕的，有多远离多远；
还好，这是网络。
#29 楼 @nightire 你把我问糊涂了，加了 turbolinks 之后，究竟可不可以用 $ -> 呢？
我升级 Rails 4 的第一坑就是这个了，当时简单的搜索了一下，发现有三个选择：
- 删除 turbolinks
$(document).on 'page:load' ->gem 'jquery-turbolinks'
当时花了两个小时试了试后两个选择，都是坑坑不止，唯有 dd 一下最爽，半秒钟解决所有问题，世界一下就清静了……
当然，我两个小时的理解肯定是非常肤浅的，你问我确不确定，我真的不确定，你知道什么说出来嘛，我希望从你的帖子中获得营养，真的。
至于说态度，你太认真了，我再说一遍，不要以自己的思维方式来理解别人。对于技术问题而言，态度是最扯淡的东西，我说它不好有我的理解和理由，理解不一定正确，理由不一定站得住脚，你如果心情好，出来指点一下我理解上的偏差，我会非常感谢你；如果你心情不好，淡定，当个笑话得了。
总之，有个东西有人喷，然后又有人不准喷，在喷的人和不准喷的人有什么区别呢？我认为理想的方式是，各自谈各自的感受和理解，言之有物，言之有据，思想有冲突才有进步，一味和谐有什么意思呢？
还有，不要对 屎 太敏感了，好吧，如果你一定不许我用屎来形容 Turbolinks，我还有一词能非常贴切的形容我当时的感受：fuck me!
关于 $ -> 能不能用
你上面给出的两个方法已经是可行的了，我不知道你转到 Rails4 的项目是什么时候，但早在去年 11 月初，我看过 Railscasts #390 之后就用过这两种方式。没错，中间也遇到过一些小问题，但是跟踪一下 Issues 都得以顺利解决。
两个小时的时间，你放弃了。我不确定这算是谁的问题，你？还是 Turbolinks？
另外，JS 是一种很灵活的语言（当然，坑更多），jQuery 也是如此。记不清从哪个版本开始了，使用 .on 方法的 delegated selector 配合 Turbolinks 也能解决事件注册的问题，你可以把：
jQuery -> # prefer jQuery to just $ personally
$('#something').click ->
$(this).doSomething
变成：
$(document).on 'click', '#something', ->
$(this).doSomething
这比写 jQuery -> 更好。WHY？看 http://railscasts.com/episodes/390-turbolinks 以及 http://api.jquery.com/on/#direct-and-delegated-events
所以总结如下：$ -> 能不能写了？如果你指的是字面意义的 $ ->，的确需要做出改变；但在满足功能的前提下，改动会不会变得很糟糕？那要看你怎么写。语言的作用是选择恰当的表达方式，而不是把嚼了一千次的梗继续当成宝。
在现代 Javascript 中，注册自定义事件是非常正常的事情，jQuery 说你可以写 $ -> 并不代表就不能用别的方法，即使是简单的 $(document).on 'page:load', -> 也没有什么可指责的。
如果你就是较真于能不能只写 $ - >这四个字母，那我只好认输，因为的确不可能比这个更少了。不过这会不会是一个问题，那还得看人。
顺便回答一下你之前某楼的提出的问题，就是说重新加载 css 和 js 的时机问题。事实上你自己也指出了在哪些状况下不使用 Turbolinks 会更合适，所以你可以使用 data-no-turbolink 来有选择的禁用 Turbolinks。
我对 Turbolinks 的看法：
1、如果是小项目，可以使用它；并根据情况有选择的使用，包括怎么写 Javascript，怎么局部禁用 Turbolinks 等等；不用怕折腾，小项目无所谓的；
2、当 PJAX 真正准备好了之后（这不是 PJAX 一个人的责任），Turbolinks 也就没太大意义了，因为根本上它违背了“把更多东西放在客户端去处理”的大趋势，这就是我为啥说它是“临时过渡性方案”的原因；
3、如果是大项目，也就是说 JS 会写的比较多，使用的插件也比较多，项目结构也比较复杂等等……请使用 JS MVC；现今较成熟的 JS MVC 框架基本上都会有针对 PushState 的解决方案，或者干脆先用 Pound Links 对付吧。
关于“态度”
我就是一个认真的人，这无可改变，而且我从未试图去改变别人，我说话的风格向来是：如果 xxx 会更好，对吗？
不要以自己的思维方式来理解别人
我从未试图去理解爱说某些字眼的那种习惯，在生活当中我也经常骂人，但是我有两个原则：
- 不骂创造性工作，即是它还不够好
- 不在公开场合骂，因为我在乎影响——对我的影响，以及我对其他的人影响
这就好比我是阿森纳的球迷，我对这个夏天俱乐部的转会动作非常不满，私下里我没有少骂过，但我从不会在论坛或是其他工作场合出口成“脏”，而且我会劝说那些已经这样做的枪迷们。尽管我知道这可能无济于事，但网络给了你“自由开火”的权利，相应的你也应该自觉承担起“清理战场”的责任。
所以对我来说，这无关于我能不能理解那些人——我当然能！然而尽己所能去平衡这个环境，去传播“怎样做可能会更好”对我而言意义更大。
有个东西有人喷，然后又有人不准喷
谁不准喷了？我么？我怎么不知道我有这么大的能力和影响力了？这是不是“受迫害妄想症”的一种症状呢？我还是那句话，我的风格向来是“如果 xxx 会更好，对吗？”即使是我很讨厌的话，我也经常用疑问句来去表达我的质疑，为什么呢？因为疑问句给出的是 options 而不是 commands。你永远有选择的权利，所以请不要说谁谁“不准”喷，因为这根本就是一种“臆测”，毫无事实根据。
思想有冲突才有进步，一味和谐有什么意思呢？
又见和谐论！我不知道在你眼中的“和谐”是什么意思，是不是“一言堂”，“只准州官放火，不准百姓点灯”，“让你说你才能说，打死也得说；不让你说你不能说，打死也不能说”等等之类的呢？
反正我是搞不懂的，每一次我跟别人说：骂人不好，表达自己的观点总有更合适的方式。总会有人跳出来跟我讲：一味“和谐”有什么意思？
那么，我是不是可以理解为：如果你不说脏字，就不能表达出你追求进步的决心和力度呢？
如果真是这样，那咱们以后每次讨论事情的时候不带脏字不允许开口，好吗？
Attitude is on option, you can choose a way or even better.
去年就在生产上用 turbolink 的人表示这东西很好。对于既有大型代码库来说提升前端体验最快的解决方案了。如果原来 JS 编码就规范的话（用 Coffee 就几乎完全没有成本），就几乎不会带来任何问题。
另外说道卡顿，你们知道元素变化的时候不加动画再快看起来都会卡顿吗？
应该叫 turbolinks，而不是 turbolink 吧-_-!!! 我没用这东西，主要是我对 js 不是太懂，不过当时@rei 推荐了的一些资料，我都很认真读过，也很有兴趣，虽然短时期都不会用上这个东西。 不管怎么样，我从这个贴子学到了不少。
rails-api+ 纯前端的 MVC 框架不好么？google，baidu 很多产品就是这样的思路（api+ 前端 mvc）...我觉得还是挺不错的。这个组合应该是一个构建复杂，用户体验较好的 web 应用的很好的基础。
#54 楼 @jamchange "右下角的按钮竟然是删除" +1 相当相当不习惯。呼唤勤劳的小蜜蜂 @huacnlee
另外取消和保存挨太近了，如果 @huacnlee 装个按键统计，我保证“取消”几乎没有人按过。
另外多说两句，很多说表单设计者都会加个“Reset”按钮，当我填了好久最后按到这个按键的时候，心里很不是滋味，这些人心里怎么想的，用户要这个 Reset 做什么？
这个网站的 C 按钮就是个例子，不过还好，只是一个单词而已。 http://www.dict.cc/
#63 楼 @huacnlee 提交回复放在右边确实会方便许多的 +1 按钮放右边是操作系统的习惯，所有的“确认”都是在右下角，包括 Linux。 另，编辑帖子好像不能用 Ctrl + Enter.
@Rei 虽然 Gmail 把按钮放左边，但不是很好的体验。用关键字 get old look of gmail back 搜一下就知道很多人抱怨现在这个新的设计。建议编辑帖子的“保存”和 新建帖子的“发布”按钮放在右边。本来我忍忍就过去了，我是发现 @jamchange 说到这个问题才在这 at 你们管理员的。
其实开个帖子让大家讨论一下就更能知道民意了。
#21 楼 @Rei 最近 2 周在用 Rails4 做公司内部的一个新项目。打算试试 Turbolinks 这些新特性。所以又翻了一遍论坛的老帖。还有你博客上面的那两篇文章。帮助真的很大。
我觉得你该把，自己写过的这段话，放在文章的开头
Turbolinks 就是个链接加速器，什么是链接？例如第一页到第二页，列表页到详细页。很多人都把它当作万能的，拿它和 jQuery 比，拿它和 Angularjs 比，然后说它怎么没有解决所有问题。那是当然的，Turbolinks 不会解决所有问题，它只是个加速器。
当我疑惑为啥我 post form 或者做 patch 动作时，整个页面被刷新了？而点链接的时候 turbolinks 就工作的很完美的时候。看看你这段，又想想这个单词 Turbolinks。我好像懂得了什么。。。
超级连接，它真的只是想解决链接的问题而已。上面喷它的人都在埋怨它不能解决超出它能力范围之外的问题。
过了这么多年我看到了这个帖子，总结一下，喷的，喷的是使用麻烦没有解决什么实质问题，他也说不出来啥，反正删了就好使了，不删就不好使。反对喷的，说了一大堆好处，我觉得你们很没意思，人家说的是人家不会使，你们说那些也没什么用。对牛弹琴而已。
