Rails 4的Asset-Pipeline / Turbolinks对于大型应用程序的优缺点是什么？
我们正在开发一个相当广泛的应用程序。 该网站将有许多不同的部分，具有一些非常不同的用户界面要求和行为。
outlook未来，Rails 4将资产管道分离为一个独立的gem，以便我们可以选择是否包含它。 turbolinks可能会发生同样的事情。
这些天我一直在问自己但无法找到答案的问题是：我应该在项目中使用这些库吗？
我反思的主要问题是，一体化文件策略可能不起作用，我们将不得不在应用程序的不同部分使用文件包。 turbolink会如何对此作出反应，因为它必须假设所有js / css已经加载？ 这种配置的优势是否克服了管道和turbolinks所隐含的代码复杂性？
我不指望是/否答案，只是对此事的一些看法。
两者都是有效的工具，不一定互相抵消。
Turbolinks：允许您仅加载页面的主体，从而使其作为AJAX请求工作（这种行为的一个例子就是Facebook拥有的）。
好处：
- 跳过完全呈现新页面的浏览器任务，从而消除了浏览器无响应的“空白页面”时间。
- 与上一篇相关：如果您的行为可能会受到加载新页面的影响，比如说，播放一首歌曲，则turbolinks不会影响它（请参阅下面的soundcloud）。
- 不重新加载文档头，因此不加载相同的标记/内容两次（如果它是相同的）。
- 使您仍然可以在服务器端缓存视图内容。
缺点：
- 拖动if标头标签确实需要更新（新的js文件，新的css文件，元标记更新……）
- 如果您想使用客户端视图呈现，那么它就不是它的工具。
- 禁用行为的默认行为是痛苦的（使用css类来禁用部分内的锚标记？这很糟糕）。
这实际上是一个问题，即你的应用程序的架构是什么，它的目标是什么。
关于资产流水线技术，我的结果好坏参半，尽管我说它有更多优点而不是缺点。 总的来说，预处理工具可以提高跨浏览器的开发效率，但不会在生产中依赖它。 但在资产流水线的情况下，它必须与你想要的一样。 你可以预处理SASS，Coffeescript，你有很棒的图书馆，如指南针或波本威士忌，但这也会增加你的性能开销。 因此，对它进行基准测试，看看它们是否适合您。
让我们从一篇关于缺点的post开始： 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就派上用场了。
- 希望这可以帮助 ：）