Trying to understand a few things about rails:
I have used rake-pipeline with rake-pipeline-web-filters successfully in the past for my front-end projects.
Recently, with a rails backend, My front-end assets are getting produced using the Rails Asset pipeline. I take it they are both similar but I am failing to align it in my head how it maps to the Assetfile way of doing things in rake pipeline.
So, questions:
Is Rake Pipeline an alternative to Rails Asset pipeline? If yes, why and what is the history & pros/cons of these two solutions? If not, how are they related?
With Rake pipeline, you addon the excellent rake-pipeline-web-filters to get all the concatenation, minification, pre-processing like scss, minispade etc. With Asset Pipeline, it seems hard to configure. One immediate limitation is that all my JS is eval'd immediately and I dont have support for minispade in the Assset Pipeline. The alternative to that is the minispade-rails gem.
In general, I am trying to understand how to go about getting a similar build process with rake pipeline Assetfile in Rails Asset pipeline.
Can someone clarify these two build processes and how to generally think about them?
Is Rake Pipeline an alternative to Rails Asset pipeline? If yes, why and what is the history & pros/cons of these two solutions? If not, how are they related?
rake-pipeline is not a direct alternative to sprockets. rake-pipeline is infinitely more flexible and more powerful. The asset pipeline is really just a preprocessor with concatenation. It does not make things like source maps and module wrapping easy. Sprockets does "dependency management". I quote dependency management because writing something =require inside a javascript file is a horrible way to "manage dependencies".
Rake pipeline defines a the steps required to build assets. This is the pipeline. Here's a build process you may think of:
Compile coffeescript into javascript
Wrap all javascript files in minispade modules
Concatenate all the files
Minify the concatenated file.
You can construct very complicated build pipeline. See Iridium's Assetfile for probably the most complex rake pipeline example in the world. Rake-pipeline is not just for constructing assets for web applications. It can be used to build any sort of code base. Ember.js uses it to construct release files for both Ember.js and Ember-Data. You could do this with sprockets, but it would be a huge waste of time and extremely awkward.
Sprockets seems to be optimized for development, where rake-pipeline is optimized for complex applications. Individual assets are available in development. This makes developing faster because assets don't have to be concatenated (only preprocessed if need be). This is not possible with rake-pipeline. Rake-pipeline only cares about inputs and outputs. The intermediate build files are not accessible.
You can use rake-pipeline inside of rails if you like. The rake-pipeline gem bundles a rails engine to replace the asset pipeline with itself. If you are building a complex frontend application I may recommend this. If you only want to wrap JS files in modules, then you can look into the various projects for the asset pipeline.
With Rake pipeline, you addon the excellent rake-pipeline-web-filters to get all the concatenation, minification, pre-processing like scss, minispade etc. With Asset Pipeline, it seems hard to configure. One immediate limitation is that all my JS is eval'd immediately and I dont have support for minispade in the Assset Pipeline. The alternative to that is the minispade-rails gem.
See previous paragraph.
In general, I am trying to understand how to go about getting a similar build process with rake pipeline Assetfile in Rails Asset pipeline.
This is impossible with sprockets. Sprockets functionality is really a subset of rake-pipeline. Rake pipeline can do everything sprockets can do and do it better. The downside is that it requires more configuration.
I recommend you take a look at assetfile I linked. It can give you an idea what you can do with rake-pipeline. Here are some thing's I've done with rake-pipeline.
Include environment specific JS/CCS (like production, development, test) etc in my final build
Allow other code to tie into my build process with hooks
Create initializer files for my Ember application
Precompile handlebars templates
Strip out assertions not required in production code.
Generate an HTML5 Cache manifest from my inputs
You could do all of these with the asset pipeline but it's not worth the effort.
Related
When I'm testing my app on a vps through sublime and sftp, these Sprockets cache files always take forever (figuratively) to sync. What are the consequences of disabling Asset Pipeline? Will my app perform noticeably poorly?
What are the consequences of disabling Asset Pipeline? Will my app perform noticeably poorly?
Yeah, the asset pipeline is there for a reason, quoting the guide:
The asset pipeline provides a framework to concatenate and minify or compress JavaScript and CSS assets. It also adds the ability to write these assets in other languages and pre-processors such as CoffeeScript, Sass and ERB.
The concatenation of assets leads to fewer HTTP requests (connection setups) which is, at least for HTTP 1.1 considered as a best practice. Minification speaks for itself I guess. Take a look at the guide to get a full grasp of the consequences.
I'm not sure what exactly you mean with sprocket cache files and which environment (as in Rails.env) you're using on your VPS.
You can also compile the assets on the VPS, which might be quicker than uploading. (See compile/precompile section in the guide).
For testing purposes you could also run in the development environment, where the assets will be compiled on demand.
I wish to try out Grunt so for a task I have duplicated a project and want to convert it from using the default asset pipeline to work all via Grunt and it's tasks.
I can then evaluate both approaches and go for what I think turns out the best.
I have disabled the pipeline in my application.rb file. I have set up my Gruntfile.js and want to first of all get it to concatenate my javascript files. I am using the grunt-contrib-concat task but what I cannot figure out is the best place to tell grunt to place the processed files?
Would it be in /public? I am just confused as to where these files will now be served from? I know that I cannot use the Rails asset helpers in my views and will have to reference them myself, but from where?
I hope you can help.
So that I could take advantage of all the already well developed front-end tools like requirejs, bower and grunt... It's just that so many of them somehow get crippled going with rails.
Primary advantages:
It is easier to load third party scripts this way. It is always possible and sometimes easy to put these through the asset pipeline, but it is also often tedious and you lose bower.
Scripts in public will not be digested, so they can be loaded by non-rails pages easily. For example, you use a javascript file on your site, and also need to load it on another, e.g., PHP site, or need to allow other people to load your script for an embedded API, etc... then you'll need to serve from public.
Primary disadvantages:
Because you're not using the asset pipeline you lose:
Asset combining and compression. Asset pipeline CSS and Javascript will be loaded in a single HTTP request each, and the content can be minified. This makes first page load on your site faster, especially if you have lots of client code or a site that needs to be super snappy for occasional visitors.
Digesting. The asset pipeline protects you 100% from cache vagaries and potentially having different users seeing your site with different version of your assets. Once you deploy, every visitor will get the new assets.
Relatively automatic etagging. Once those visitors get the new assets, their clients will generally cache them for a long time. Rails can afford to let assets cache essentially forever because digesting ensures you're not punished for this later.
So there are pros and const both ways and neither is right or wrong.
It's just that so many of them somehow get crippled going with rails
Pipeline
The reason is you're not meant to use the likes of Grunt etc with Rails. Rails' asset pipeline is only meant to contain the files which can be precompiled & used directly in your application:
The asset pipeline provides a framework to concatenate and minify or
compress JavaScript and CSS assets. It also adds the ability to write
these assets in other languages and pre-processors such as
CoffeeScript, Sass and ERB.
This will typically mean compiled third party JS/CSS files, and your own application JS/CSS files. I don't see how something like Grunt would provide any benefit to this? All it does it create a way for you to manage dependencies, versioning & source of particular assets?
--
Public
Using the files in your public folder isn't such a big deal. One of the most prominent things it does do is to exclude those particular files from the file digest processs, allowing you to use the likes of endpoints (scripts) which can be accessed by other services (outside the scope of routes.rb)
A good example of this is when we created an analytics system, and put the analytics.js into the public folder, so all the widgets could access it. This allowed other sites to access this file, regardless of the state of the asset pre-compilation.
One caveat to this would be you could perhaps have some way to store a "pseudo" file in the public folder, with it routing dynamically (with ERB) to the precompiled equivalent, but I've got no experience with this
--
Pipeline
The benefits of keeping your assets inside the asset pipeline, as stated by gwcoffey, are:
They will be compiled as you design (I.E primarily into application.js, but also into any other files you define too)
You don't need to worry about versioning (every precompile is basically a way to better the version without worrying about grunt etc)
You can include as many dependencies as you want - meaning you're able to create a totally modular set of assets which can be used throughout your app; rather than single scripts which will have their own dependency base
Recommendation
Unless you maintain third-party scripts which need dependencies to run, I would not recommend using Grunt for Rails. If you develop your own JQuery / Javascript scripts, by all means run them through Grunt etc; but for use in your app, I'd steer clear
Hope that helps!
I'v seen some larger emberjs implementations like discourse: https://github.com/discourse/discourse/tree/master/app/assets/javascripts/discourse
Can someone explain to me how this gets integration into rails?
What happens behind the scenes when the asset gets compiled? To the files just get minified and merged or there is more to it?
You need to read about Asset Pipeline.
The directory you linked to above is included by the various require lines in app/assets/javascripts/main_include.js, which is itself included by app/assets/javascripts/application.js.erb.
The gem doing the heavy lifting (the one responsible for interpreting the require lines) is Sprockets.
What happens behind the scenes when the asset gets compiled? To the files just get minified and merged or there is more to it?
Between the asset pipeline docs and sprockets' docs, your very general question should be more than answered. In a nutshell, yes, the files are minified and merged, and yes there is a whole lot more to it.
In addition to reading about the Asset Pipeline and Sprockets (which handle JS minification, etc), also take a look at the ember-rails gem: https://github.com/emberjs/ember-rails
ember-rails allows you to include Ember.JS into your Rails 3.1+ application. The gem will also pre-compile your handlebars templates when building your asset pipeline. It includes development and production copies of Ember.
We've implemented Jammit for asset caching, compression and optimization in our Rails application. It's fully integrated with our continuous integration process and works well. That said, I am seeing 3.1 introduces a new canonical asset pipeline based on Sprockets.
Are there advantages to the Sprocket based approach that would merit porting our system? I do not want to spend time converting our system if there are no benefits.
I have already used Sprocket and Jammit and the main advantage of the Rails 3.1 approach is the complete and native integration of Sprocket, not the gem itself. I'm not a specialist but both gems are great and, for me, equivalent.
The rails 3.1 assets pipeline provide a clean architecture for js and css files and the native use of associated gems (sass, coffee-script, sprocket). If in your app you already have a clean tree for your files and a great integration of your gems, don't change anything !