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.
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 ?
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: 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).
Advantages:
- Skips the browser task of fully rendering a new page, thus eliminating the "blank page" time where the browser is unresponsive.
- Related with previous: In case you are having behaviour that might get affected by loading a new page, like let's say, playing a song, turbolinks will not affect it (see soundcloud next).
- Doesn't reload the document head, therefore not loading the same tags/content twice (if it is the same).
- Enables you to still cache view content on the server side.
Disadvantages:
- A drag if header tags really need to be updated (new js files, new css files, metatags update...)
- If you want to use client-side view rendering, it is just not the tool for it.
- The default-behaviour to disable the behaviour is just painful (using css classes to disable anchor tags inside a section? that just sucks).
It's actually a question of what the architecture of your app is, what does it target.
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.
Let's start with a post about the drawbacks: http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-effect.html
If this isn't a problem for you: http://geekmonkey.org/2012/09/introducing-turbolinks-for-rails-4-0/
To wrap things up: Turbolinks will improve your page load significantly if your pages share JavaScript and CSS styling. PJAX comes in handy, when server-side performance is an issue.
- Hope this helps :)
来源：https://stackoverflow.com/questions/14231616/what-are-the-pros-and-cons-of-asset-pipeline-turbolinks-from-rails-4-for-a-big-a