I am researching asset packager gems for Rails. I found out that Rails has its native solution to this problem in the cache=>"all" option on the include tag helpers. There is also some discussion about whether this is good enough, and some gems like Jammit have their diehard defenders. If there is a native solution to packaging javascript assets, why do we need an asset packager gem?
The native asset packager, which is engaged using the :cache option, only concatenates the JavaScript and CSS files, but doesn't minify them. Other packagers may go further in this regard.
Using the native packager and gzip compression tends to produce results comparable to, yet never superior to, a fully minified packager.
Related
I'm working on using a Grunt workflow to manage my assets in my Rails app rather than Sprockets.
So far, I have my apps JS and CSS both being concatenated and minified into public/assets/javascripts/application.js and public/assets/stylesheets/application.css respectively.
And also have my Bower components JS and CSS being concatenated and minified into public/assets/javascripts/vendor.js and public/assets/stylesheets/vendor.css respectively.
Fonts and Images from Bower components are then copied into public/assets/(images|fonts).
This is all well and good but now I need the references to fonts/images within those files to be updated to reflect their new location.
I have looked at cssmin and yes it rewrites file references but I cannot get the file path to change depending upon the type of file being referenced.
Any ideas on how I can do this?
Also, I ahve been reading about Grunt plugins which can read your view files and use those to minify and concatenate files and update the and tags in the views for you.
Surely I can't do that in a Rails app? Is there a way I can deal with this in Rails?
This other StackOverflow post may be of help:
Integrate Grunt into Rails asset pipeline
The accepted answer recommends using the Half Pipe gem.
The second answer linked to a blog post about a Do-It Yourself solution: Goodbye, Sprockets! A Grunt-based Rails Asset Pipeline.
I haven't used either solution, but they are worth a try.
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 always have ruby gem of famous javascript or css lib such as bootstrap-sass, ember-rails. But for some js lib such as bootstrap-lightbox, there are no gems sometimes. In order to manage these asset automatically, I found the jail(https://github.com/charly/jail) gem. But it seems that project is not so active now. Are there any better solution then just download and past file?
Many of those "assets gems" are just a basic skeleton with js/css assets, it should not be too hard to build your own and publish on rubygems!
An advantage of this, beside locking versions in Gemfile, is that you have control over them and don't risk screwing everything up during a bundle update.
I have found issues using external gems for managing assets, especially with bootstrap ones, sometimes the precompilation will break or they will upgrade the assets inside, breaking the entire site (or minuscole portions that you may hardly notice) with not-so-wanted changes.
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 !
I want to compress css files and javascript files in my project. Is there any plugin to do that? :">
I used bundle-fu, worked great.
compresses both css and javascript
has no external dependencies
is around for a long time (proven)
is simpler to use than Jammit (no config file).
more
Jammit is newer and fancyer.
it has better compression as it can use the latest compressor from google Closure Compiler considered having the best compression
is harder to use than bundle-fu (makes you define a config file)
has external dependencies (the java runtime to run the closure or yui compressors, written in java).
I use Jammit for this.
Rails 3.1 will do this automagically, as Ryan Bates shows in his Rails-3.1 Overview.