I'm serving a semi-static site with rails, just to get used to rails conventions.
Do I really need to use the asset pipeline to serve the .css and .js?
I could always precompile my .scss and coffee-script before their on the server.
and by semi-static, I mean that I may include some gems to do syntax highlighting or some other little tasks.
I guess it would be good practice?
I'm super new to rails and programming in general, by the way.
I just want another opinion.
Thanks, in advance.
You should use the asset pipeline if you are using rails 3.1 or above. It is far faster than the previous serving of assets in rails -- among other things, it munges and minifies the files.
You should always precompile your assets in production, whether or not you are using straight .css or .scss because if you don't precompile your assets, rails will still have to compile them at runtime.
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 need to use my sass stylesheets for another non-rails site (a Wordpress blog), so I need to compile them into a css file without the file fingerprinting from the asset pipeline. I saw this related post:
Rails 4 Asset Pipeline: Compile both with and without fingerprint
However, it doesn't seem to give me the non-fingerprinted stylesheet I'm looking for
Rails 4 has documentation for this.
Just set
config.assets.digest = false
in your environment configuration file (for example config/environments/production.rb)
http://guides.rubyonrails.org/asset_pipeline.html#turning-digests-off
There is a gem called non-stupid-digest-assets which allows you to determine which files are "fingerprinted" and which are not.
#config/initializers/non_digest_assets.rb
NonStupidDigestAssets.whitelist = ["your_file.js"]
You'll then be able to call it your_file.js as well as using asset_path asset_path("your_file.js")
Some gems for ruby on rails needs precompiling their assets. For example CKEditor for rails. I have integrated by this guide. There was some code for assets.rb that will add precompiling.
Then I have run rake assets:precompile and it created a lot of files, I mean A LOT OF FILES, inside my public/ckeditor path.
Does this precompiling make my application operate faster?
The short answer is yes.
Here's a nice article about how precompile works.
Essentially all of your CSS and JS is minified and put into a single file when possible. This avoids the overhead of making multiple http requests to different resources. Precompile also does some magic with cache control for those resources and images alike.
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.
I've used jammit to do my asset packaging so far, but my next application will be in Rails 3.1
Should/Can I still use Jammit? Or should I work with the built-in asset pipeline?
You can still use Jammit, but the built in asset pipeline is The Rails Way™.
I'd recommend you try out the asset pipeline/Sprockets - if you don't like it, it's as simple as moving the javascript and css files back to the public directory and setting up Jammit the old way.
I found that setting up the asset pipeline the first time around for browser specific css was a little non-intuitive, but, that was just me being unfamiliar with the whole process. Sprockets works well and allows you to use ERB/HAML with your coffee script or sass (if you want.)