Front-end Strategy with a sprinkling of ExpressionEngine

My aim in the past while has been pointed towards front-end development, and exploring the different ways in which to produce a tidy result.

These examples point to ExpressionEngine paths, but you can customise them to any project you’re working on. I’m relatively new to the ExpressionEngine game, and some of what I’m going to outline will be eventually replaced by Niall O’Brien’s EE Foundation generator, so that’s definitely something to keep an eye on.

As with many things, we start with Gulp. This will handle our assets and do some nifty things such as generating our critical CSS and automatically injecting our Bower components whenever we update them. See below for an example setup:

This is just the standard-fare Gulp setup. We’ve got tasks for watching and compiling our assets. It’s the structure of these assets that I want to talk about.


I’m using Sass (SCSS syntax), and I’m borrowing heavily from MVCSS for the structure. It’s a simplified version (i.e. I’ve left things out) to a point where I find it easier to manage.

A typical folder structure would be :


This is the foundation of the project, where we establish defaults on tag-level elements, define variables, layouts, mixins… The files in here might go as follows:

  • _base.scss — our tag-level styles.
  • _config.scss — definition of our variables, fonts etc…
  • _helpers.scss — mixins, placeholders, utility classes.
  • _layout.scss — grid-type classes.
  • _reset.scss — I like to use normalize.css


These are the building blocks of our project, and each component gets it’s own file. This helps isolate styles so they don’t leak into other components — it’s about making a more reusable code-base. You might have files like _button.scss or _panel.scss.

And the rest

To tie this all together we have a main.scss file that imports all of the above, including, if you’re anything like me, a _shame.scss file. I’ve written some horrible, horrible things. Things I’d rather forget. Thanks to the shame file I don’t have an excuse any more.

I’m also a fan of the BEM naming convention for CSS. This great post by Harry Roberts explains it better than I ever could.


I’ve aimed to manage my JavaScript in the same way as my CSS. I have a main.js file that pulls in all my modules, and Browserify does the rest.

What I’m doing is using wiredep to insert my Bower components into the page, then including my main.js file. This ensures my custom scripts have access to the likes of jQuery, or Foundation.

I’ve also created a little script that lets you monitor what Foundation breakpoint you’re on.

So you can run MQ.isSmallOnly() or MQ.isMediumUp().


EE Master Config has made optimising for different environments very simple. For example, I want to serve the critical CSS on a live site, but the standard unminifed version on my dev machine:

I can do this with scripts as well.

I’m out

That’s all I’ve got. This is my day off. There’s still a lot more to consider and refactor, but I think it’s a good starting point.