Between the rise of CSS preprocessors, frontend frameworks like Foundation and Bootstrap, and the nearly de facto requirement for all sites to be responsive, the style-specific code we’re writing is far beyond adding link tags into the head of your HTML.
There are plenty of resources speaking on how to best architect your frontend code, but I’ve run into some practicality issues when trying to implement many of them. For one, many of the architecture patterns don’t take in account that you might be utilizing a third-party framework or other boilerplate code, which doesn’t adhere to said conventions.
Two, many of the architecture patterns are great for building web applications, but web sites are a slightly different beast. Web sites don’t have as many repeating design patterns, at times contain superfluous stylistic elements, and in general are a little less structured than a web app.
Lastly, on nearly every one of our client projects, we’re getting last minute design changes requiring quick fixes for rapidly approaching launch dates. This means we need a codebase that is lightweight and able to (as effectively as possible) organize some less than ideal implementations before more formal refactoring can take place.
At Authentic F&F we’ve built a frontend boilerplate which we use as a starting point for all our web site projects. It’s an amalgamation of a frontend framework, some sass architecture, and a few internal conventions we use to quickly dive into our projects. The goal of the repo is to create a codebase that is powerful, scalable, and flexible.
With this article, I want to review this internal framework speaking on some of the decisions we’ve made, and what we’re still looking to improve upon. In an article down the road I’ll go over the other frontend tools we use to process and build our code, but for now we’ll stick to the libraries and architecture we utilize.
A while ago we made the decision to base the code we are writing on Zurb’s Foundation framework. Originally we made this decision as we felt that Foundation was a little more lightweight than the other major player, Bootstrap, and since making this choice, we’ve been very satisfied with Foundation.
Out of the box Foundation gives you a lot of boilerplate code. One look at the documentation, and you can see this for yourself. On the majority of our projects, we comment out many of these components. Being that Foundation is built on Sass, and features a very flexible import file, we’re able to pick and choose required components based on the task at hand.
A few Foundation features we utilize regularly:
The settings.scss file allows you to adjust the default settings Foundation ships with. You can adjust colors, grid properties, and breakpoint dimensions. On nearly every project we’re using this file for adjusting the grid dimensions utilize in our visual designs.
Foundation.scss is the file which holds all of the individual Foundation component imports. We have modified the boilerplate of this file quite heavily, removing a majority of the imports.
Things like buttons styles, form styles, and table styles are things we’re typically designing from scratch while we are slicing the designs, but if an app is a little less custom and these styles end up being needed, it’s easy to re-include them in the project.
The grid component of Foundation is by far our most utilized feature. The grid itself is pretty straight forward to use, utilizing grid-specific classes you apply to various div and container elements of the html.
By default the grid ships with 12 columns, of which you can nest infinitely within each other.
The grid also comes with support for varying grid sizes, on multiple different break points.
For example, say we have 4 divs sitting horizontally next to each other. Each div we want to take up 1/4 of the screen on a desktop display; each div should take up 1/2 of the screen on tablet; and each div should take up the entire screen on mobile. The syntax for this would be:
<div class="row">
<div class="small-12 medium-6 large-3>Div 1</div>
<div class="small-12 medium-6 large-3>Div 2</div>
<div class="small-12 medium-6 large-3>Div 3</div>
<div class="small-12 medium-6 large-3>Div 4</div>
</div>Pretty slick.
Similar to the grid-specific classes, Foundation comes with visibility classes to display content based on individual breakpoints.
On many of our projects, mobile optimization requires hiding content not important enough to show on mobile, when we want the user to only be reading the most important content on the site. In these cases hiding the less important content via this classes is convenient.
An example would be:
<div class="row">
<div class="small-6 medium-6 large-3>Div 1</div>
<div class="small-6 medium-6 large-3>Div 2</div>
<div class="show-on-medium-up medium-6 large-3>Div 3: Not necessary for mobile</div>
</div>In this example, we’re doing something similar to the example in the Grid section; however on the small (mobile) breakpoint, we’re only showing 2 of the divs, and hiding the 3rd.
The show-on-medium-up class does exactly that: only shows the content for the medium breakpoint, and anything above it.
Inside the SASS itself, we’re writing quite a few media queries to handle styles that can’t be adjusted with the grid and visibility classes themselves. Foundation comes with predefined variables to assist with this.
For example, if you want to write a media query that only applies to the small breakpoint:
@media #{$small-only}{ color: red;}It’s important to note that when writing your styles, you are adding them from smallest to largest, within the SASS files.
For example, to adjust paragraph colors, use this approach:
p{
color: black;
@media #{$medium-only}{
color: yellow;
}
@media #{$large-up}{
color: red;
}
}Note the default style on the paragraph tag applies to the small breakpoint, the medium breakpoint has it’s own style, and anything large and up is red. If you add the large media query before the medium, you can get some style conflicts.
When we were deciding between Foundation and Bootstrap, one consideration was the notion of LESS vs SASS. At the time, Foundation was SASS and Bootstrap was LESS. We were somewhat partial to SASS, and also the helpful SASS library Compass, of which Foundation utilizes. Making the decision to go with Foundation solidified this choice for us, and since then have been taking advantage of both these libraries.
After we decided on the Framework to go with, and in turn the preprocessor we would be using, the next big decision is how do we want to structure .scss files for the project itself.
The implementation we currently have in place was loosely based on the SMACSS architecture advocated by Jonathan Snook, and breaks down the files into a few different working groups: Layout, Modules, Elements. I use the term “loosely” because it’s very loose. While we use some of the same nomenclature, which correlates to a few similar concepts, the way we have implemented this is much less rigid than SMACSS.
Running through our scss directory, we’ve got several folders, each with their related files. All of these files are included in this app.scss file, which handles importing of Foundation as well as the project specific sass files (in the correct order). All of these styles get compiled into our app.css file, using grunt.
Our current sass architecture is:
chrome.scss
Sitewide display chrome; ie: sitewide background images, macro-level display or container styles.
interactions.scss
Typically animations (hovers, popups, etc) that we want to define on a global level.
layout.scss
Setting up major layout elements; ie: paddings and margins on containers and how different modules should interact with each other.
typography.scss
Defining our high-level styles used across the site; ie: headings, p, a, blockquotes, variations within previous listed tags.
buttons.scss, forms.scss, lists.scss
Components are fairly standard html elements we use on nearly almost every site. These are styles we don’t really consider modules as they are too generic, but still individual pieces of a site we want to have their own file for organizational purposes.
colors.scss, typography.scss, variables.scss
These files store sitewide variables and mixins we use throughout the rest of the files, to help us with some often used and long winded style declarations.
This directory holds all of the Foundation framework files. Nothing custom going on in here.
The modules directory has a file for each different module we have across the site. General modules like header.scss, footer.scss, and navigation.scss are used on nearly every project. As we are slicing the front-end of a website, and begin to build out individual modules, we start adding unique module files, like _callout-carousel.scss, to this directory.
It’s important to note that we typically have a lot of module files. It’s not uncommon to have in the range of 10-20 individual files, some which only have a handful of styles inside.
We’re of the opinion that while it can be annoying to create all these files, it makes the codebase much more scalable, as you don’t have a massive file with all sorts of mixed definitions cluttering each other up. As modules grow and evolve, you have adequate space in each file to expand things, without worrying about a long unorganized file with multiple module definitions.
3rd_party_overrides.scss
Whether it’s something from Foundation we need to override, or another style from a JS or SCSS plugin we’re using, this file holds ugly overrides for these annoying (but necessary) styles.
ie.scss
You hopefully know what this one is for :)
normalize.scss
The css reset.
shame.scss
I believe Chris Coyer was the one who we saw advocating for this, but the shame.scss file holds all the hacky stuff you need to implement, but wish you didn’t need to. It holds hacks, and workarounds that either can’t be easily fixed, or maybe we don’t want to implement a more in depth fix that would be a poor use of time.
global_mixins.scss, type_mixins.scss
These files hold global mixins and typography mixins we used in various configuration sass files.
While I feel very confident with this internal framework of sorts, I don’t deny that it has it’s shortcomings. The biggest one, in my opinion, is that while it separates modules, components and elements into different files, it could do a better job of articulating a more thoughtful way of implementing these components in the HTML and SASS files themselves.
At the end of the day we’re still using classes and ids to style things, and just calling them elements, components, or modules; based on a subjective understanding of how widely used they will be on the site. At some point I’d like to implement the Attribute Modifiers technique, creating a more concise way to declare these components, both in the HTML and SASS. If you aren’t already familiar, I’d recommend giving this a read. I was pretty blown away myself, with how elegant the technique is: http://amcss.github.io/.
With the internal framework outlined above, we’re able to quickly jump into the responsive development of a website, without needing to write the tedious boilerplate code found on nearly every project. It’s safe to say that this combination of Foundation, file architecture, and some internal mixins and default styles, saves us 10-15 hours on each project, and lets us tackle the majority of responsive development during our first pass of slicing the designs.
While we’re not necessarily doing anything groundbreaking, hopefully this gives you some insight into how we successfully straddle the grey area of framework vs customization, and how it applies to developing web sites.
Subscribe here to get our short and sweet monthly newsletter!
