Rails 4的Asset-Pipeline/Turbolinks对于大型应用程序的优缺点是什么?

Pie*_*her 11 ruby ruby-on-rails asset-pipeline turbolinks ruby-on-rails-4

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

展望未来,Rails 4将资产管道分离为一个独立的宝石,以便我们可以选择是否包含它.turbolinks可能会发生同样的事情.

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

我反思的主要问题是,一体化文件策略可能不起作用,我们将不得不在应用程序的不同部分使用文件包.turbolink会如何对此作出反应,因为它必须假设所有js/css已经加载?这种配置的优势是否克服了管道和turbolinks所隐含的代码复杂性?

我不指望是/否答案,只是对此事的一些看法.

Chu*_*ckE 11

两者都是有效的工具,不一定互相抵消.

Turbolinks:允许您仅加载页面的主体,从而使其作为AJAX请求工作(这种行为的一个例子就是Facebook拥有的那个).

好处:

  • 跳过完全呈现新页面的浏览器任务,从而消除了浏览器无响应的"空白页面"时间.
  • 与上一个相关:如果您的行为可能会受到加载新页面的影响,比如说,播放一首歌曲,则turbolinks不会影响它(请参阅下面的soundcloud).
  • 不重新加载文档头,因此不会加载相同的标记/内容两次(如果它是相同的).
  • 使您仍然可以在服务器端缓存视图内容.

缺点:

  • 拖动if标头标签确实需要更新(新的js文件,新的css文件,元标记更新......)
  • 如果您想使用客户端视图呈现,它就不是它的工具.
  • 禁用该行为的默认行为是痛苦的(使用css类来禁用部分内的锚标记?这很糟糕).

这实际上是一个问题,即你的应用程序的架构是什么,它的目标是什么.

关于资产流水线技术,我的结果好坏参半,尽管我说它有优势而不是缺点.总的来说,预处理工具可以提高跨浏览器的开发效率,但不会在生产中依赖它.但是在资产流水线的情况下,它必须与你想要的一样好.你可以预处理SASS,Coffeescript,你有很棒的图书馆,如指南针或波本威士忌,但这也会增加你的性能开销.因此,对它进行基准测试,看看这些是否适合您.