over 8 years ago from Evan Knight, Design @Google
I’m working with about 10,000 lines of (desktop and mobile web) SCSS/CSS, which I’m aiming to minify and restructure. How do you structure your SASS for scalable projects? And do you use SMACCS, OOCSS, or BEM?
I use a combination of SMACSS, OOCSS and BEM.
Here's a screenshot of how I've organized the Sass in one of my most recent projects:
I hope this gives you a bit of context. I also now include a z-index as well in the core to manage all of my z-index values. I consider modules any elements that could be considered reusable throughout your project.
BEM can become verbose so I try to extend classes when possible, even using silent classes. In my naming convention, I personally don't use underscores. Hyphens as separators and double-hyphens as a modifier.
If you have any specific questions feel free to ask, and I'd be more than happy to answer them to the best of my knowledge and ability.
Nice! Thanks for sharing.
1.) Interesting that you have folders within pages, and it looks like a .scss file for each page. Do you find it easier or harder to manage than having a header.scss, and body.scss?
2.) Since you have files for individual pages, do you use unique class names and format them using something like @include grid_6 similar to this? Or do you use bootstrap style
in your markup?1) Every page does have its own .scss file, but many times it's modifying a module. For example, there's .hero but in the home.scss file, I'll have .hero--home and have it modify the background-image. Occasionally it'll have it's own page-specific element, which that'll go there as well.
I don't like having page-specific modifying classes in a global module. I find that it's easier to have a separate file for page-specific stuff, even if it only has a few lines.
I don't think it's harder. It's just a few more steps to create and import the file when you have a new page, but I find the separation easier to manage in the long-run.
2) Reiterating some of my first answer, for individual pages most of the time it's modifying classes, whether I'm extending an existing class or with BEM doing a --modifier.
I used to use Foundation, but I've migrated to using Neat http://neat.bourbon.io/ nowadays. More often than not I find myself creating my own breakpoints. I do not use Foundation/Bootstrap style markup (if you're asking if I do things like class="large-columns-6 medium-columns-5 small-columns-4"). I try to keep much of that logic in my CSS + media queries.
Nice Jonathan. Your answer is almost mine exactly: 
I have greatly simplified the structure over time. Nearly everything is a module that isn't part a Base element. No more layouts, pages, or even a states folder.
I have a more detailed write-up on my combo strategy, naming patterns, states, etc - if anybody cares Objects in Space.
Cheers. -adc
Hey Evan, How are you? I love your Theme IDE. what is this? A theme on sublime text?
Thanks :-)
I will never understand the micro-structuring that some people use. I use the following:
...and then a folder called 'page', in which I have stuff like:
...etc. I see no reason as to why it should be more fragmented than this.
It's just preference. I just started co-working with a developer who has the same preference as you — putting almost everything into one big main.sass file or whatever, and I like to break mine up into much smaller pieces — into modules, and a file for each page, etc., and what I realized when talking to him is that he would prefer one long file with almost everything in it, scrolling to different modules and pages that are separated by comments over switching to a different file, whereas I would much prefer many short files that don't require much scrolling or searching, and find it easier to see where things are located if they have their own file, which is name accordingly.
He prefers to search/scroll, I prefer to open up a new file. It's just preference.
I'll tell you one thing though, in terms of passing code along and picking up on a project I think it'd be much more clear to a developer where things are located if they are broken up into smaller pieces. For example, looking at your sample file structure, if I came in to do some work on the forms I'd say "Hmmm...which file are the form styles in....let me search..." — but if they were in _forms.sass I'd know immediately. No searching! Make sense?
Yeah I mean I get normal structuring, but some of the examples I see are borderline crazy in terms of micro-ordering.
It reminds me of when I was a musician and there were musicians who spent all their time putting pedal boards together, soldering awesome cables and putting it all in fancy flight cases....and then there were musicians who actually played music. ;)
In terms of your example, I wouldn't mind adding a _forms.sass file to make it easier. But adding a forms file inside core/pages/login/mobile/whatever to target a specific mobile login just seems long winded to me.
Oh, gotya. Yeah, I haven't really found a need to ever split folders into sub-folders, and I've worked on a project that had quite a large code-base, though again, to each their own — I'm sure there are situations in which it makes sense, though I'd share your hesitance when it comes to getting that minute with it.
I separate my files into three categories:
I'm considering adding a fourth category for layout, but it can be hard to keep that separate from other styles sometimes…
Asked the same thing some time ago, take a look at the answers :)
I use CSS Burrito, a structure and set of tools developed by one of my coworkers. It's good stuff: https://github.com/jasonreece/css-burrito
I like the commentary on how Medium structures their LESS files; breaking it down by modules first, and then by pages as it becomes necessary.
Definitely read this if you haven't already: https://medium.com/@fat/mediums-css-is-actually-pretty-fucking-good-b8e2a6c78b06
I'm using a convention that I follow for my views, scripts and stylesheets. Basically it looks like this :
Keep in mind that my CoffeeScript ( compiled to javascript ) is also using the same convention
for the mods, you can delete ":, but I" :)
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now