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:
Disadvantages:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With