Skip to main content

Building your static site with Hugo, FlightJS, SASS and Gulp

Hugo provides a good workspace for creating layouts and content. I'm very much satisfied with the options available to customise the site. However, Hugo does not have a say in how CSS and JavaScript should be structured so that it can be included on our site. In Hugo, the DOM nodes are already created and we need a mechanism which we can employ in adding event listeners to these DOM nodes.

SPA frameworks like Angular and React, create DOM nodes and define event listeners in the controller of the component. To attach event listeners to an existing DOM tree I came across a JavaScript framework called FlightJS. It's a framework created by folks at Twitter that helps in adding behaviour to the DOM nodes. It's a minimal framework which does not dictate how the DOM nodes should be rendered nor it dictates the other aspects of the web application, such as routing, request/response handling, structuring data so that other components can consume it etc. FlightJS provides only a mechanism that enables us to add behaviour to the existing DOM nodes.

This is exactly what I needed to build my static site. Let's take a look at how I have structured my site using SCSS, FlightJS and Gulp for building the static content:


I have created an 'src' directory in my Hugo site which will contain all the JavaScript and SCSS files. Hugo's documentation suggests that we need to keep all static content (JavaScript, CSS, images, font files etc) in 'static' directory. Here 'src' directory will contain the development code i.e. unprocessed SCSS files and non-minified JavaScript files. The 'static' directory, on the other hand, will contain CSS code (processed SCSS) and minified JavaScript files which are production ready.

In our example, the FlightJS code can be included in 'js/pages/home/index.js' file. Here's the code which creates a FlightJS component, defines a 'click' event handler and attaches the component to an existing DOM node:

FlightJS has a dependency on jQuery and thus you see jquery.js present in the 'vendor' directory. A lot can be done with FlightJS, however, I'm restricting this post to build a proof of concept which demonstrates the minimal functionality.

The next step is to add a build process that compiles the SCSS files, compress and concatenates JS files and creates a hash for these files for browser cache busting. I'm using GulpJS to create a pipeline build and here's the sequence:

  1. Compile SCSS files - compile 'pages' and 'vendor' files separately.
  2. Concatenate the vendor related CSS files.
  3. Move the generated files to 'static/css' directory.
  4. Compress the JS files - 'pages' and 'vendor' files separately.
  5. Move the generated files to 'static/js' directory.
  6. Use 'gulp-hash' to create a hash for the generated JS and CSS files. Create a hash manifest file and place it in the 'data' directory (assets_js.json and assets_css.json).

The gulpfile.js used to build the pipeline can be referred here:

After compiling and generating content in the 'static' directory, you can refer to these files in your layout templates:

<link href="{{ .Site.BaseURL }}css/vendor/vendor.css }}" rel="stylesheet" type="text/css">
<script src="{{ .Site.BaseURL }}js/vendor/vendor.js }}"></script>

Here the template variable {{ .Site.BaseURL }} would be replaced with the baseUrl defined in the config.toml file and when the generator creates the static files, it would be referring to the file '<site>/css/vendor/vendor.css' and '<site>/js/vendor/vendor.js'. Since we are creating adding a hash to these files, it would not be possible to refer to 'vendor.js' and 'vendor.css' files like this. However, we can use the manifest files created when generating a hash for referring these files.

As noted in the last step of the Gulp build process, we are creating manifest files 'assets_js.json' and 'assets_css.json' in the 'data' directory. The content is a JSON structure that contains hash references:


Hugo can read files in the 'data' directory and it supports TOML, YAML and JSON file formats. Now we can modify our template to get the hash refernce from the asset files:

    href="{{ .Site.BaseURL }}css/{{ index .Site.Data.code_assets.assets_css "vendor/vendor.css" }}"


    src="{{ .Site.BaseURL }}js/{{ index .Site.Data.code_assets.assets_js "vendor/vendor.js" }}">

The template variable '.Site.Data.code_assets.assets_js' will contain reference to the values in the file 'data/code_assets/asset_js.json' and the reference key 'vendor/vendor.js' would return the value assigned to it (vendor/vendor_f8da36b2.js).

Code is shared on my github repository here:


Popular posts from this blog

Adding beforeRender and afterRender functions to a Backbone View

I was working on a Backbone application that updated the DOM when a response was received from the server. In a Backbone View, the initialize method would perform some operations and then call the render method to update the view. This worked fine, however there was scenario where in I wanted to perform some tasks before and after rendering the view. This can be considered as firing an event before and after the function had completed its execution. I found a very simple way to do this with Underscore's wrap method.

De-obfuscating javascript code in Chrome Developer Tools

I had blogged about JavaScript debugging with Chrome Developer Tools  some time back, wherein I have explained how these developer tools can help in debugging javascript code. Today Google Chrome 12 was released and my Chrome browser was updated to this version. As with every release, there have been some improvements made on performance, usability etc,. One feature that stood out for me is the ability to De-obfuscate the javascript code. What is Minification? Minification is the process of removing unnecessary characters such as white spaces, comments, new lines from the source code. These otherwise would be added to make the code more readable. Minifying the source code helps in reducing the file size and thereby reducing the time taken to download the file. This is the reason why most of the popular javascript libraries such as jQuery are minified. A minified jQuery file is of 31 KB in size where as an uncompressed one is about 229 KB. Unfortunately, debugging minified javascript f

Custom validation messages for HTML5 Input elements using the constraint validation API

HTML5 has introduced several input types such as EMAIL, URL, RANGE, SEARCH, DATE, TIME, etc,. Most of the modern browsers have implemented them and are ready to be used in a HTML document. Another exciting feature introduced in HTML5 is the form validation. Instead of writing JavaScript to validate users input, browsers can now validate it and show an appropriate message if the validation fails. The validation message is shown in line with the field for which the validation has failed. The default error message is shown when the validation fails. In this post I'll explain how these error messages can be changed.