对于大型应用，Rails 4中的Asset-Pipeline/Turbolinks的优缺点是什么？

Question

我们正在开发一个非常大和广泛的应用程序。该网站将有许多不同的部分，与一些非常不同的用户界面要求和行为。

展望未来，Rails4将资产管道分离为一个独立的gem，因此我们可以选择是否包含它。同样的事情也可能发生在turbolinks上。

这些天我一直在问自己的问题是:我应该在我们的项目中使用这些库吗？

我的思考中的主要问题是，一体化文件策略可能不起作用，我们必须在应用程序的不同部分中使用文件包。turbolinks会对此有什么反应，因为它必须假设所有的js/css都已经加载了？这种配置的优点是否克服了管道和涡轮连接所隐含的代码复杂性？

我不期望得到一个是/否的答案，只是对这件事的一些看法。

Answer 1

这两个都是有效的工具，不一定相互抵消。

Turbolinks:使您能够仅加载页面的正文，从而使其作为AJAX请求工作( Facebook就是这种行为的一个例子)。

优势：

soundcloud soundcloud跳过了完全渲染新页面的浏览器任务，从而消除了浏览器使用unresponsive.

• Related的“空白页面”时间:如果你的行为可能受到加载新页面的影响，比如播放一首歌，
• 将不会影响它(参见soundcloud next)。
• 不会重新加载文档头，因此不会两次加载相同的标记/内容(如果相同)。
• 使您仍然可以在服务器端缓存视图内容。

缺点：

• 如果标题标签确实需要更新(新的js文件，新的css文件，元标签update...)
• If )如果你想使用客户端视图渲染，它只是不适合它的工具。
• 默认行为禁用行为是痛苦的(使用css类禁用一个节中的锚标签？这太糟糕了)。

这实际上是一个关于你的应用的架构是什么，它的目标是什么的问题。

关于资产管道，我对它的结果好坏参半，尽管我会说它的优点多于缺点。总体而言，预处理工具提高了跨浏览器开发的效率，但在生产中并不依赖它。但在资产管道的情况下，它必须与您想要的一样好。你可以对SASS、Coffeescript进行预处理，你有很好的库，比如指南针或波旁酒，但这也会增加你的性能开销。因此，对其进行基准测试，看看这些工具是否适合您。

Answer 2

让我们从一篇关于缺点的帖子开始：http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-effect.html

如果这对你来说不是问题：http://geekmonkey.org/2012/09/introducing-turbolinks-for-rails-4-0/

总结:如果您的页面共享JavaScript和CSS样式，Turbolinks将显着提高页面加载。当服务器端性能是个问题时，PJAX就派上用场了。

• 希望这能有所帮助:)