As soon as a ported a large stylesheet and turned it into 8 smaller '_xxx' partials and made a set of 4 layouts, the compile time for SASS jumped up to unworkable delays...in terms of vetting changes and iterating through solutions. I did have to include @imports for Compass/Singularitygs/Breakpoint into the files (at least the layouts...if not the partials) and that may be lagging, but interestingly I am NOT using the @extend with nesting that many people seem to link to increased times. Here is my bundle info (running on Ubuntu):

Using addressable (2.3.5)
Using chunky_png (1.2.9)
Using fssm (0.2.10)
Using sass (3.2.13)
Using compass (0.12.2)
Using breakpoint (2.0.7)
Using timers (1.1.0)
Using celluloid (0.15.2)
Using coderay (1.1.0)
Using compass-blend-modes (0.0.2)
Using color-schemer (0.2.8)
Using compass-normalize (1.4.3)
Using compass-rgbapng (0.2.1)
Using compass-validator (3.0.1)
Using css_parser (1.3.5)
Using eventmachine (1.0.3)
Using http_parser.rb (0.5.3)
Using em-websocket (0.5.0)
Using ffi (1.9.3)
Using formatador (0.2.4)
Using rb-fsevent (0.9.4)
Using rb-inotify (0.9.3)
Using listen (2.4.0)
Using lumberjack (1.0.4)
Using method_source (0.8.2)
Using slop (3.4.7)
Using pry (0.9.12.4)
Using thor (0.18.1)
Using guard (2.3.0)
Using guard-compass (1.0.0)
Using multi_json (1.8.4)
Using guard-livereload (2.1.1)
Using guard-shell (0.6.1)
Using oily_png (1.1.0)
Using rb-fchange (0.0.6)
Using sass-globbing (1.1.0)
Using sassy-strings (1.0.0)
Using singularitygs (1.1.2)
Using susy (1.0.9)
Using toolkit (1.3.8)
Using yajl-ruby (1.2.0)
Using bundler (1.5.2)

Some web articles seem to indicate that this may be a general SASS 3.2 problem and that the solution is SASS 3.1. Would a reversion of this sort harm any of the project workflow you are presenting on various videos and documentation? Are there more elegant solutions?

For instance...why is it that a partial can be included in the compile 'cascade' ... but not a layout using '@import "layouts/**/*" in a central aggregation file??? When I do that I still get an error for missing definitions of mixins from (i.e.) Compass, but I CAN use a Compass mixin for a file-partial stored in the components folder using "@import "components/**/*"! Is this JUST because of the naming protocol using the underscore prefix...in other words could I do a Layout with a name like "_NameOfLayout" and get the juice of not having to "@import" Compass for the layout and just use my main css file importation mentioned above?! Surely this would cut way down on compile time!

Comments

MhueD’s picture

MhueD CreditAttribution: MhueD commented
Issue summary: View changes
timoti’s picture

timoti CreditAttribution: timoti commented

Having the same issue. With the help of a cool ruby guru - operating outside of his core competencies - we got compile down to 20-30s by making various imports much more specific - much better but still unacceptable And yes - my code is an @extend free zone.

Ideally I'd just be using libSASS for uberfast compiles, via codekit 2.0, but this isn't at all straightforward either, and there's no surety that sourcemaps are supported yet, operating in codekits 'hybrid' libsass/ruby approach. There is a lot of info out there on optimising for better css, but not actually for the compile time.

I'd really value any update on this issue - which runs a way back now - this and the dance of dependencies (even with RVM/bundler) taken days out of my life and I just want the nightmare to end. Will of course share any thing else I can come up with.

stormpat’s picture

stormpat CreditAttribution: stormpat commented

.

BenMirkhah’s picture

BenMirkhah CreditAttribution: BenMirkhah commented

Heavy use of compass mixin @include background() had slowed my compile time, just a hint.

luisfmsouza’s picture

luisfmsouza CreditAttribution: luisfmsouza as a volunteer commented

Have you tried to use Grunt to compile sass instead of Ruby gems ?

We improved our time by 60% just with this migration.

fubhy’s picture

fubhy CreditAttribution: fubhy commented

I added a very lightweigt LibSass based starterkit to Omega today and named it "Default". The Ruby based Starterkit previously named Default is now called "Dusty".

Was about time.

osopolar’s picture

osopolar
Primary language German
Location 🇩🇪 GER 🌐
CreditAttribution: osopolar commented

Thanks a lot @fubhy.

Could this be changed for current projects without breaking anything or is it recommended to use only for new projects? Are any instructions what I have to change for current project to switch from Dusty to Default (LibSass)?

fubhy’s picture

fubhy CreditAttribution: fubhy commented

@osopolar First and foremost you are probably going to have problems with dependencies you built your Sass around with the previous starterkit... Namely stuff like Compass, Singularity/Susy, etc. .... Oh wait, let me just put together a quick list of things you might want to look at if you choose to migrate (it's definitely possible but tough to say for me whether it will end up being complicated in your specific case).

1. Copy the new/changed files from the starterkit's root directory to your theme and remove all the old stuff from your theme (e.g. Gemfile, config.rb, package.json, .ruby-version, Guardfile, etc.). Take the files from the new default starterkit (e.g. gruntfile.js, package.json, ...) and copy them over to your theme (if you added any npm packages, make sure you copy them over from the old package.json).

2. Remove the old node_modules directory and do a fresh "npm install".

3. As mentioned... Compass/Susy/Singularity etc. (basically all the ruby gems you are currently using, if any). Try to look out for things like https://github.com/Igosuki/compass-mixins ... You are not the only one migrating away from ruby gems for these mixin libraries so it's very likely that you will find resources for all sorts of things.

4. Adjust your styles.scss and normalize.scss: Globbing (import with **/*.scss) does not work in libsass and there is no sass-globbing plugin as there was for the ruby preprocessor. Hence, you now need to explicitly @import all your partials yourself (check your styles.scss file for that, there should a few **/*.scss-style imports). Then, according to #3, migrate away from compass/singularity mixin usage or find compatible non-ruby replacements for these.

fubhy’s picture

fubhy CreditAttribution: fubhy commented

Oh, and in order to run gulp, either use your global gulp-cli (if installed) or run the package.json scripts (e.g. "npm run sass:dev") --> watches your /sass folder for changes and compiles the .scss with libsass using gulp.

osopolar’s picture

osopolar
Primary language German
Location 🇩🇪 GER 🌐
CreditAttribution: osopolar commented
Status: Active » Fixed

Thank you very much fubhy for explaining all this. I consider switching to LibSass for the current project, but not immediately. I created a new follow-up issue to collect the experiences, as I won't be the only Omega 4 user who will migrate to the new LibSass starterkit.

So far, I guess this issue could be closed as fixed - at least I hope that the LibSass will be as fast as people told.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.