Gulpin’, Gruntin’, or none of the above: Front-end build process

We will briefly discuss and demonstrate the various popular front-end compiling tools, discuss which tools we prefer and why, as well as the exploration and experimentation behind relying on Drupal for compiling needs.

Current front-end workflow benefits from the use of a few fresh technologies, white currently are not standardized. Drupal front-end development means familiarity with LESS, Sass and likely SMACSS. This is especially true as we move closer to a D8 release date. Both LESS and Sass need some form of compiling to produce browser-compatible CSS: GUI-based or command-line based.

There’s now a multitude of supported frameworks, mixin-libraries and preferred methods of integration. Today's chart-toppers include task runners like Grunt and Gulp, and Sass frameworks like Compass, Susy, and Singularity. Grunt and Gulp are both task runners with associated plugins; able to offer a plethora of tasks as by their communities. Compass, Susy and Singularity are all frameworks used to produce front-end layouts with reduced investment of effort. Compass also provides short-hand mixins for various CSS behaviors.

The front-enders at Chapter Three came together to discuss standardizing projects; a goal that had raised much contention in the past. We couldn’t agree on much outside of using Sass as our preprocessor and Susy as our layout framework. Susy’s flexibility is it’s primary strength. Instead of producing pre-set containers, it produces reusable grids on-demand. We felt other frameworks were too cumbersome and bloated. Lately the majority of our front-enders have been using Gulp to compile via the command-line due to it’s speed and community support.

We’ve also recently experienced a resurgence in commenting importance. It's more helpful than expected when handing-off projects to other developers, both in-house and out-of-house. Be informative, be verbose, be honest; even “todo” comments are helpful and reduce the barrier-to-entry to theme-development.

Since tools come with their own learning curves, we try to leverage Drupal for more of our build process. This lowers the barriers of entry for Drupal developers looking to crack into the build process landscape. Increasing the complexity of a project is bad for all parties, and using Drupal to power your build process removes unnecessary moving parts.

Drew Bolles
I first started building sites back when GeoCities was all the rage, spending my nights as a kid learning HTML and CSS. Fast-forward a few years, and I'm still viewing sources and reading A List Apart articles. I'm passionate about developing scalable, reusable architectures that not only look great, but are built with good semantics and performance as a feature. I love building sites that cater to as many users as possible, and that harness the universality of the web.

Casey Wight
With a background in design, development and Drupal, I bring a diverse set of skills to the Chapter Three team. My initial jump into the web-development forway began in the dark days of tables and frames. I’ve worn multiple hats over the years (Creative Director, Developer, Client Relations, Scoundrel, etc) but my main focus has always been getting my hands dirty in code. Now I’m designing and developing flexible and scalable Drupal front-end systems with a top-notch team. I pride myself in creating dynamic layouts using scalable and sustainable architecture.