Rails 4的Asset-Pipeline/Turbolinks在大型应用程序中的优缺点是什么? [英] What are the pros and cons of Asset-Pipeline/Turbolinks from Rails 4 for a big application?

问题描述

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

We're working on a pretty big and wide application. The website will have a lot of different sections with some very different user interface requirements and behaviors.

展望未来，Rails 4将资产管道分成了一个单独的gem，因此我们可以选择是否包含它. Turbolink可能会发生同样的事情.

Looking into the future, Rails 4 separated the asset pipeline into a separated gem so we can choose to include it or not. The same thing might happen with turbolinks.

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

The question I keep asking myself these days and can't find an answer is: should I use theses libraries in our project or not ?

我反映的主要问题是，多文件合一的策略可能无法正常工作，我们必须在应用程序的不同部分中使用文件捆绑包. Turbolink如何对此作出反应，因为它必须假定所有js/css都已加载?这种配置的优点是否可以克服管线和turbolink所隐含的代码复杂性?

The main issues in my reflection is the fact that the all-in-one file strategy will probably not work and we'll have to use file bundles in the different parts of the application. How is turbolinks going to react with this, because it must assume that all the js/css is already loaded ? Does the advantages of such a configuration overcome the code complexity implied by both the pipeline and turbolinks ?

我不希望答案为是/否，仅是对此事的一些看法.

I do not expect a Yes/No answer, just some opinions about the matter.

推荐答案

两者都是有效的工具，不一定彼此抵消.

Both are valid tools which do not necessarily cancel each other out.

Turbolinks:使您仅可以加载页面的正文，从而使其可以作为AJAX请求使用(这种行为的一个示例就是Facebook的行为).

Turbolinks: Enables you to load only the body of a page, thus making it work as an AJAX request (an example of such a behaviour would be the one Facebook has).

优势:

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

缺点:

• 拖动是否确实需要更新标头标签(新的js文件，新的css文件，元标签更新...)
• 如果要使用客户端视图呈现，它不是用于此目的的工具.
• 禁用行为的默认行为是很痛苦的(使用css类禁用部分内的锚标记?这很烂).

这实际上是一个问题，即您的应用程序的体系结构是什么，它的目标是什么.

It's actually a question of what the architecture of your app is, what does it target.

关于资产流水线，我的看法不一，尽管我会说它的利弊大于弊.总体而言，预处理工具可提高跨浏览器的开发效率，但在生产中不要依赖它.但是在资产流水线的情况下，它必须与您想要的内容做得很好.您可以对SASS，Coffeescript进行预处理，并拥有指南针或波旁威士忌等出色的库，但这也可能会增加性能开销.因此，对它进行基准测试，看看这些是否适合您.

About asset pipelining, I have had mixed results with it, even though I'd say it has more advantages than disadvantages. Overall, pre-processing tools enhance cross-browser development productivity, but don't rely on it in production. But in the case of asset pipelining, it has to do as well with what you want it for. You can pre-process SASS, Coffeescript, you have great libraries like compass or bourbon, but this can also increase your performance overhead. So, benchmark it and see whether these should be tools for you.

这篇关于Rails 4的Asset-Pipeline/Turbolinks在大型应用程序中的优缺点是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！