Hugulp, a Hugo + Gulp toolchain
Wordpress is the undisputed leader for blog management, even including hosted solutions such as Wordpress.com.
But what are the alternatives and what do they bring to the table ?
Here, I’m sharing Hugulp, a blog workflow based on Hugo and Gulp.
Not all blogging engines are the same
There are basically two types of blog-creating engines:
- Dynamic generation
- Static generation
Wordpress is dynamically generated as in, each time a page is requested, the content is retrieved from the underlying database, converted to a format suitable for the web and then presented to the user.
As you may imagine, this adds time to the reader’s perceived speed of your blog.
On the other, statically generated blogs, have the pages created beforehand, so when they are requested by a browser, all that needs to be done is to present them to the reader.
There are many of static generation engines, but the most popular are:
They all have their merits and faults, but ultimately all of them will create a site that can be served faster than any Wordpress site.
Perhaps the two features that can create a distinction are ease of installation and site generation speed.
Hugo, being a single cross-platform binary, is the easiest to install. Also, it’s arguably the faster.
Hugulp
Having decided on Hugo, I created a workflow that would allow me to replicate the famous Ruby on Rails Asset Pipeline.
The basic premise of the Asset Pipeline is to minify, concatenate and fingerprint the assets used in your blog (images, stylesheets, scripts) so that less (and smaller in size) network requests are made by the browser.
This creates a better user experience for the readers of your blog.
Hugulp uses Hugo to generate the site’s content and Gulpjs, to perform the steps required for the asset pipeline.
UPDATE (Jan 2017): I’ve decided to turn Hugulp into a standalone tool, so the structure shown below has changed, while keeping the core concepts. Check out https://github.com/jbrodriguez/hugulp, for more details.
So, the folder organization for a Hugulp project will be
- hugo
Contains the standard hugo install. The content subfolder contains all Markdown documents which will become separate blog articles. - gulp
Each file here describes a separate gulp task. This improves sharing and readability of the tasks. - src
It’s the master copy of all the asset files (css, js, jpg, png, svg, etc.). - staging
It holds processed assets, as an optimization step, so that specially images compression doesn’t need to run during each build.
Gulp manages the entire build and to get a better idea of this works, let’s simulate the processing for one single asset, *style.css* (style.scss to be more specific), and follow its transformation through the build pipeline.
The blue boxes represent the file (and its path), the green boxes represent a gulp task, that performs some processing:
To recap, this is what happening
- The styles, scripts and images tasks get executed first to do the heavy lifting of compressing images and minifying css/js files.
- The revision task runs next to fingerprint the optimized assets.
- Then the hugo task is invoked to generate the static site
- The reference task replaces all asset ocurrences with their fingerprinted versions
- Finally, the browser is reloaded so that you can very quickly check the changes you made
This entire process runs under a second in my Macbook, so the feedback is instantaneous.
Conclusion
There are other options besides Wordpress, so your hands are not tied.
Hugo is a solid solution, that combined with the power of Gulp, provides a very rewarding workflow.
-
This article is an excerpt of a two-part series originally published on jbrodriguez.io
