12

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

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

这些天我一直在问自己却找不到答案的问题是：我应该在我们的项目中使用这些库吗？

我反思的主要问题是，多合一文件策略可能不起作用，我们将不得不在应用程序的不同部分使用文件包。turbolinks 对此有何反应，因为它必须假定所有 js/css 都已加载？这种配置的优势是否克服了管道和 turbolinks 所隐含的代码复杂性？

我不期待是/否的答案，只是对此事的一些看法。

4

2 回答 2

11

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

Turbolinks：使您能够仅加载页面的正文，从而使其作为 AJAX 请求工作（这种行为的一个示例就是 Facebook 所拥有的）。

好处：

  • 跳过完全呈现新页面的浏览器任务，从而消除浏览器无响应的“空白页面”时间。
  • 与上一个相关：如果您的行为可能会受到加载新页面的影响，例如播放歌曲，turbolinks 不会影响它（请参阅下面的 soundcloud）。
  • 不会重新加载文档头，因此不会两次加载相同的标签/内容（如果相同）。
  • 使您仍然可以在服务器端缓存视图内容。

缺点：

  • 如果标题标签确实需要更新（新的 js 文件、新的 css 文件、元标签更新......）
  • 如果你想使用客户端视图渲染，它只是不适合它的工具。
  • 禁用该行为的默认行为是痛苦的（使用 css 类来禁用部分内的锚标记？这很糟糕）。

这实际上是一个问题，即您的应用程序的架构是什么，它的目标是什么。

关于资产流水线，我的结果好坏参半，尽管我会说它的优点多于缺点。总体而言，预处理工具提高了跨浏览器的开发效率，但在生产中不要依赖它。但在资产流水线的情况下，它必须与你想要的一样好。你可以预处理 SASS、Coffeescript，你有 compass 或 bourbon 等很棒的库，但这也会增加你的性能开销。所以，对它进行基准测试，看看这些是否应该成为你的工具。

于 2013-01-09T11:08:42.703 回答
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 就派上用场了。

  • 希望这可以帮助 ：）
于 2013-01-09T10:33:06.053 回答