When you use Haml and Sass, does it slow things down all the time or just for the first time the view is rendered?
I'm sure it isn't a big performance penalty, but just curious as to how things are rendered.
As Michael and jxpx777 said, Sass gives you only a one-time slowdown. Haml, according to this benchmark, is as fast as Erb (assuming Haml 3 hasn't gotten slower than Haml 2.2). So the answer is, no it doesn't slow things down all the time.
Haml (like Erb, I will assume) has a precompiler, so it does some work up-front and then spits out the rendered views pretty fast.
Not sure about haml. Sass will spit out a .css file when rails starts up so once it's created it has zero effect on speed as the web pages reference the outputted .css file.
HAML shouldn't have too much performance difference to ERB. It's the same kind of process. SASS will experience a performance hit the first time it has to generate the CSS files, but I do that as part of my Capistrano deployment script so that no users have to see that performance hit.
If you use this while writing your SASS, you'll not have any slowdown whatsoever, as it generates (and syntax checks) your SASS as you write it:
sass --watch screen.sass:screen.css
HAML is not slower than ERB.
Related
I'd like to add source map support on a rails 3.2 application I am working on. As far as I know, generating source maps is not supported by Sprockets and from its github page it looks like the feature is planned for 4.0. I am working with Sprockets 2.2 and I think monkey patching is the only way to go. The module Processing under the main Sprockets module gives access to the js_compressor function which can be patched to generate source map for a single file. But, I don't know how to add this when the JS files combine. I am using Uglifier 2.4 as the compressor.
The project has a mixture of CoffeeScript, JS and EJS files. So, I think this is how sprockets would be compiling them together. First, it would convert Coffeescript and EJS to JS, then use the js_compressor to compress individual files and later concatenate them in groups. Now, as the source map for multiple files combined to the same file is a single file. So, I will need to change the compilation process somewhat and make the js_compressor run over the files, once the concatenation is finished. So, can anyone help out with this? Even explaining the sprockets compilation process and the modules used and functions involved would be of great help. I don't care about making source map files for the CoffeeScript code at present. Even mapping to their converted JS files would do.
Also, would like to add if there is some gem which can help with this it would be most welcome.
Rails 4 does not have source maps either.
As far as I know, and as of today, this will only be part of rails 5.
A really nice approach to solve this right now is implemented in discourse by #SamSaffron and explained here:
https://github.com/discourse/discourse/blob/master/lib/tasks/assets.rake
The gist, add a "before" task to the sprockets precompile process, and hack into the compilation process to generate the sourcemapped files and directives.
The nice thing in this approach is that you don't lose stuff from files that are both js and erb (*.js.erb) which is something quite common in rails.
I think that patching the whole sprockets pipeline is a bit of an abuse and risky.
I'm currently using the less-rails gem in a Ruby on Rails application that I'm building. I would like some way to debug my Less css files in Chrome by way of source maps (https://developers.google.com/chrome-developer-tools/docs/css-preprocessors) Does anyone know how this can be accomplished?
In my opinion, the most convenient way to solve the problem: to abandon the assets pipeline and less-rails. change to gulp or blendid with gulp-less+gulp-less-sourcemap. This will take time to configure, but as my practice shows, the loss of time more than pays off with features like life edit, very fast compilation, and of course - sourcemaps.
In fact, I personally did not use less in such a bundle, but the implementation of sass is very convenient. I think that with less it could be the same
You can use pry to debug in rails. So, whereever you are using your css in the haml or html you can write something like -binding.pry( if its haml). Pry is used for debugging ruby code but you can also use it in your haml(view) using -.
https://github.com/pry/pry
Hope this helps.
I'm working on an email newsletter using ActionMailer that's associated to our Rails 3.0.7 application. So against all my instincts, I'm using inline styles like mad since that seems to be the only way to do things in html email. I'd also like to keep the color scheme consistent with the website in a DRY fashion.
Is there any way to share SASS color variables between a Rails application and its SCSS files for use in inline styling?
The only way I'm aware you can do this is to add .erb onto your sass files so that they're processed by Rails, then you can use application level constants:
<%= APP_CONFIG[:yourkey] %>
Similar question / more reading
Coding emails is such a heinous task that I try to turn off all the higher thinking regions of my brain that worry about good programming principles every time I have to do it. Unless email is the central part of this project I'd resist letting the constraints there affect the rest of your application design.
Best solution I've found so far is the premailer gem: https://github.com/alexdunae/premailer/
Post-processing your HTML with premailer inlines all the CSS defined in a separate stylesheet, letting you specify whatever you want in a SASS or CSS file.
I've seen that certain Rails CMSes (like Radiant) have plugins that essentially compile Sass when a page is accessed. Is there a way to do this in a regular rails app? Is doing so performant? Basically, I'm looking at a way to remove the extra step of running Compass to compile my stylesheets.
I've not used compass specifically but there looks like there's a production flag so files are compiled - I couldn't imagine they'd build it to recompile per request in production, Radiant compiles it's css on Application startup and if you then commit those generated CSS files it doesn't try to generate them again AFAIK.
http://compass-style.org/docs/tutorials/production-css/
Sass and Compass automatically integrate with Rails. If you're using Rails 3, all you have to do is add gem "haml" to your Gemfile and all .sass and .scss files in public/stylesheets/sass will get compiled to .css files in public/stylesheets.
Compile per request? I think it could be a hit for performance. You should definitely use a caching strategy in that case. So that it compiles the stylesheet only if it is not in the cache.
You could create a helper method setup_stylesheet that will take care of setting up the css stylesheet. You call this method on the application layout.
setup_stylesheet will check if the css stylesheet is on the cache, and if it is there then use it. If it is not, then compile it.
Another approach:
You could set up an initialiser that will call Compass to compile your SASS stylesheets when the App is launched.
Is doing so performant?
There will be a massive performance hit when compiling at run-time.
As Nex3 (author of Sass gem) pointed out on another forum, there's no need any need to run compass watch.
I strongly advise putting the following into production.rb: Sass::Plugin.options[:never_update] = true - this is especially important if you're on Heroku. (you could also do this in your rack file, where you can also specify other options
Hmm, good luck
For a rails CSS framework for an existing app, which one do you prefer - LESS or COMPASS?
Less and Compass are not really direct competitors.
LESS is a CSS engine. Compass is more a toolbox around SASS/SCSS and Blueprint CSS framewok. So if you want to use Blueprint in your project, use Compass.
You should take a look at LESS syntax and SCSS syntax and choose the one your prefer. But they both are now a superset of CSS 3 and they have more or less the same features.
Another thing to know is that SCSS/SASS is still included in HAML gem. So if you want to use HAML...