Introducing Tales from the Front Weekly

I started a weekly newsletter for all things front-end. Sign-up to get an email every Friday morning.

Getting Started with Gulp

I recently discovered a new javascript based build automation tool called Gulp by @wearefractal. It's extremely simple to learn and use and can easily compete with gruntjs for a variety of different projects. It's so easy you'll be a Gulp expert after watching these slides. Well almost, here I'll go through a couple steps to get you started.


In your project folder install the gulp module:

$ npm install gulp

Next, download a gulp plugin like gulp-minify-css or gulp-swig

$ npm install gulp-minify-css gulp-swig

Then create a Gulpfile.js file.

// Gulpfile.js

var gulp = require('gulp');
var swig = require('gulp-swig');
var minifycss = require('gulp-minify-css');

// compile, minify, and copy templates
gulp.task('templates', function(){

// minify and copy styles
gulp.task('styles', function(){

gulp.task('default', function(){'templates', 'styles');

  // watch files and run scripts if they change"./src/templates/*.swig", function(event){'templates');
  });"./src/assets/css/*.css", function(event){'styles');


This example gulp file has 3 tasks: swig template compilation (templates), css minification (styles), and default (default). Each can be run on the command line separately:

$ gulp templates // or
$ gulp styles // or
$ gulp

In this example, the default task runs both the templates and styles tasks plus starts a watcher method that watches for changes to particular files and then runs a specified task when the file changes.

That's it, I think it's all pretty self-explanatory. I've written a couple plugins for it already that I've been using in my projects: gulp-swig and gulp-html-prettify.

DOM Horror with EmberJS

I started using the Javascript framework, EmberJS, after using AngularJS for a few months. So far, there's a level of friendliness in Ember that I don't see in Angular. There's a nomenclature within Angular that is a little foreign to me and has made the learning curve a little more steep for me.

After spending a few weeks getting familiar with Ember, going through the documentation and tutorials, I really started getting into it. I feel very productive with it.


There's something about Ember that you should be aware of that I hadn't noticed at first. I opened the DOM inspector in Chrome to see the generated HTML, and I found something that looked similar to this nightmarish chunk of HTML:

<div id="ember162" class="ember-view">
    <h2>Welcome to Ember.js</h2>

    <script id="metamorph-1-start" type="text/x-placeholder"></script>
    <script id="metamorph-0-start" type="text/x-placeholder"></script>
        <script id="metamorph-5-start" type="text/x-placeholder"></script>
        <script id="metamorph-2-start" type="text/x-placeholder"></script>
            <script id="metamorph-6-start" type="text/x-placeholder"></script>
            <script id="metamorph-6-end" type="text/x-placeholder"></script>
        <script id="metamorph-2-end" type="text/x-placeholder"></script>
        <script id="metamorph-3-start" type="text/x-placeholder"></script>
            <script id="metamorph-7-start" type="text/x-placeholder"></script>
            <script id="metamorph-7-end" type="text/x-placeholder"></script>
        <script id="metamorph-3-end" type="text/x-placeholder"></script>
        <script id="metamorph-4-start" type="text/x-placeholder"></script>
            <script id="metamorph-8-start" type="text/x-placeholder"></script>
            <script id="metamorph-8-end" type="text/x-placeholder"></script>
        <script id="metamorph-4-end" type="text/x-placeholder"></script>
        <script id="metamorph-5-end" type="text/x-placeholder"></script>
    <script id="metamorph-0-end" type="text/x-placeholder"></script>
    <script id="metamorph-1-end" type="text/x-placeholder"></script>

My jaw dropped. I was completely horrified! All that code just to render this:

    <h2>Welcome to Ember.js</h2>

And this is the code that's generated right from their starter template!

Yeah, the ember docs explain it so I get why it has to be that way. Nevertheless, it's something that has been hard for me to accept. I don't see anything like that being generated by Angular. This seems like an awful lot of bloat that could potentially make it harder for you to style your pages.

I'll continue to use Ember but I think this needs to be fixed.

Static Site Generation With Docpad (Part 2)

< Part 1

Setting Up

The simplicity of setting up Docpad was one of the reasons I chose it over Octopress. The Docpad Getting Started Guide is a great intro, so start there. The only difficulty I had was in getting my site deployed to Github Pages, using the Docpad plugin. The Docpad deployment guide makes a lot of assumptions about your level of understanding of how Github Pages works. This is all they provide from the docs:

npm install --save docpad-plugin-ghpages
docpad deploy-ghpages

This installs a plugin that manages pushing your output to Github. However this assumes that you've already created a github repo that the Pages site will be pointing to. It assumes you want to deploy to a gh-pages branch of the repo. This is wrong. To publish a blog to Github Pages, you need to push to your master branch. According to the Github Pages documentation, gh-pages is reserved for project landing pages, not regular site/blog pages.

This is all too confusing. Instead of using the docpad github plugin, I decided to just push the output folder directly to the master branch of my repo using standard git commands. I had to reconfigure Docpad slightly so that the output folder and all the source code were set up separate folders. I recommend setting up your files this way:

    ├── OUTPUT (
    │   ├── icons
    │   ├── img
    │   ├── index.html
    │   ├── posts
    │   ├── scripts
    │   ├── styles
    │   └── vendor
    ├── SOURCE (
    │   ├──
    │   ├── node_modules
    │   ├── package.json
    │   └── src
    │       ├── documents
    │       ├── files
    │       └── layouts

To do this, you just need to tell Docpad where it should save the output. You do that by modifying the file. Per the config docs, you just need to set the outPath

outPath: '../OUTPUT'

This will allow you to create and maintain two separate repositories, one for the output (which gets pushed to Github Pages), and the other for your source code.

Deploying to Github Pages with your own Domain

I decided to host my site on Github, primarily because it's free, but also because it's super convenient to commit and push, then serve everything with the same service.

As briefly explained above, Github Pages works via a specially named repository dedicated for that purpose. If you create a repository named: [username] anything within the master branch of that repository will get hosted out on http://[username] So, for instance, my repository: is hosted out on (which redirects to

The next step is to point your domain to the Github Pages IP address. Currently, this IP address is: but check the docs just to make sure, since it's possible it could change. Next, checkout the Setting up a custom domain with Pages, doc. It tells you to create a CNAME text file with your domain name, in the root of your pages. So for me it was like this:

    ├── OUTPUT (
    │   ├── CNAME <--- contains ""

Once you've committed that to your repo and pushed it up, and you've setup your domain to point to the right IP address, it should take Github about 10 minutes (plus the time for DNS cache to clear which could be an hour or more) to listen for that domain.

And that's it. If you have any questions or need any assistance, leave a comment below or find me on twitter.

Static Site Generation With Docpad (Part 1)


Since this is my first blog entry, I think it makes sense for me to talk about the technology behind it a little. The whole site is statically generated on my Macbook using Docpad, and deployed to Github Pages.

"Going static" seems to be the trend within the coding community, and for good reason. Though static site generators are not at all new, I think a couple development trends have factored into it becoming a popular choice with developers.

  1. Git all the things!
    Maybe it's just me but I really love using Git. It just makes managing my projects so much more sane. Branching, merging, committing, are all now just a natural extension to development that I almost don't even have to think about it anymore. Now that I'm thoroughly accustomed to this kind of workflow, I find myself increasingly frustrated with managing Wordpress blogs. To do any development, I have to maintain at least two different MySQL databases, one for development and one for production. Then you have to repeat everything you did locally on your development box, such as installing plugins, and theme development, just to get your changes into production. With a static site, I can work completely local, commit my statically generated pages into git, and then push them up to my site. One version control source for both code and data.
  2. The rise in laptop development
    Another big contributing factor in the popularity of static sites is that most developers I know work almost exclusively local. They do all their coding on their laptops. There are so many tools that help with this that it makes it so there really is no reason not to anymore. Logging into your live site through an admin interface, in my opinion seems outdated and cumbersome and leaves your site open to potential security exploits. Now that we're all working locally, it's the next logical step to just administer our blogs locally as well.

So, what is Docpad?

Docpad is a static site generator built in NodeJS and Express. What this means is that Docpad gives you a set of tools that lets you code your site using templates and layouts, and all the other things you're used to using for building dynamic sites. The difference is that it will generate all your pages as plain old static HTML pages, out to an output folder that can be served by any web server (including through localhost using Express).

I chose Docpad over other popular choices (Jekyll and Octopress) because it's less complicated to set up - and it's written in Javascript!

In the next post, I will walk you through getting setup with Docpad and publishing to Github Pages