Our front-end development boilerplate
Grunt, SASS, and everything in-between
tl;dr The frontend boilerplate we use for starting new sites is now posted publicly here: https://github.com/kps3/kps3.boilerplate
Grunt, Gulp, SASS, LESS, Handlebars, Underscore, Bower, and 100 different front-end development tools have been created over the last few years. What happened? Seriously, what the hell happened?
Front-end coding has changed dramatically over the past three years, and we’ve felt it at KPS3. Our projects have grown in size, and with that, in complexity. What used to work for a simple two page website doesn’t work for a large-scale web app or 800 page State website. After months, or more realistically, years, we have finally narrowed down our front-end development process and started documenting it.
We started by creating our boilerplate. The boilerplate is the basis for all new projects. It’s a combination of several different tools, and has undergone several different versions. You can see where it stands today here. Note, our boilerplate requires several prerequisites: Node (for npm), Compass (gem install compass), andGrunt (npm install -g grunt-cli).
Foundation vs every other framework
We started using Foundation early on. It was one of the first responsive frameworks we used—and I’m happy we picked it. The simplicity and ease of learning, using, and adapting foundation to any project has made it a staple in our workflow. We don’t even create a site nowadays (unless specifically requested) that doesn’t use foundation as the base layer. This was our first real step in standardizing our front-end development stack.
SASS vs LESS
We started using LESS. It was our first dip into the world of advanced front-end development—and it didn’t go too well. We started using the javascript compiler that would just compile everything client-side. Terrible idea—don’t do it. We then moved to using a variety of LESS compilers, eventually landing on using a Watcher for PHPStorm. Things finally started to work well. We all used PHPStorm. We all used the Watcher. Our settings were all the same. Life was grand. And then we hired Jonathan Rutheiser.
Jonathan joined the team about 7 months ago and has really helped us focus our front-end strategies. Armed with a wealth of SASS, Compass, and Mixins knowledge, he convinced us that LESS was the wrong approach. Sure, there are ways of getting the support for LESS, but it just wasn’t as easy as getting everyone up and running with SASS & Compass. (Oh, and Foundation adopted SASS as their preference and the two play wonderfully together.) We all converted to SASS, and just kept using our Watcher in PHPStorm to compile everything. Just a minor change and all was right again. But, as our team grew we had to adapt our setup to work outside of a specific code editor. Each developer has a different coding style, a different editor of choice, and different settings unique to their environment. It wasn’t fair to ask everyone to use PHPStorm. So, we began modifying our process again.
Grunt vs. Gulp
To be honest, I can’t remember why we chose Grunt over Gulp. I’m pretty sure Gulp didn’t exist at the time, but I don’t know. Anyway, it doesn’t matter at this point. If you haven’t checked out Grunt, you really should. It’s fantastic. To explain it simply, we use grunt to enhance and compress our CSS and JS, optimize our images, and easily manage different templates and partials. If you’re interested in the details of what add-ons we use, go take a look here.
The Git Repo
So, how do we keep this all organized? We are constantly tweaking and enhancing our setup, and updating the “_Starter Template Folder” on our client server wasn’t cutting it. We didn’t know when it was updated and it was impossible to track our changes / updates. Git was the perfect solution—our designers, front-end devs, and back-end devs already all collaborate through it, so let’s use it for more than client projects. We created the boilerplate repo and we each have it cloned down to our machine. Having our boilerplate in a Git repo makes updates a breeze and you can be sure you always have the latest version. It also makes it super easy to track updates, bugs, and continuously improve the project.
Our process for each project
- Open Terminal and navigate to the boilerplate repo on your machine.
- Do a “git pull” to receive any updates/bug fixes that may have happened since you last used it.
- Copy the files from the boilerplate directory and paste them into your new project directory.
- If you’re good with the basics, run “npm install” (you may have to sudo depending on your configuration).
- If you’d like to add anything more custom, run “npm install [package-name] —save-dev”. This will install the module and add it to your package.json so others will get it.
- Since we’re using both Grunt and Compass, there are two config files you can edit to your specifics needs: Gruntfile.js (grunt) and config.rb (compass).
- Now that your settings are configured, navigate to your project directory in Terminal and type “grunt watch”. This will watch the directory for any changes. As files get saved and changes get made, Grunt will recompile all the styles, javascript, templates… basically all the magic.
Taking it further
This is just a starting point. It may seem daunting at first, but it’s actually extremely easy after you get the hang of it. This combination of tools and process has allowed us to move faster with our front-end development and write cleaner, better code. We’re able to split up our template files how they’d actually be split up in an app development environment and create a more modular way of organizing our files. (Side note: this is a HUGE help when multiple developers are working on one project; having everything split out and modular has cut down on painful merge conflicts a ton.)
Now, I won’t say it’s perfect. We’re still running into some issues with different people’s tab sizes, tabs vs. spaces, and overall just coding styles—but I’d gladly take those issues over going back to front-end coding three years ago.
KPS3 Frontend boilerplate repo: https://github.com/kps3/kps3.boilerplate
Have any ideas on how it can be better? Found a bug? Contribute!
