Generating a static website

October 18, 2016

When I decided to create this blog, I wanted it to be easy and cheap to maintain. I chose Github Pages for it's free hosting and stumbled on Jekyll. Jekyll is a static website generator that is mostly meant for blogs. Github Pages supports Jekyll out of the box, so that Jekyll builds the site automatically everytime you update the content. Jekyll is a great tool for simple blogging, but with it comes lots of conventions and restrictions how to do things. I was looking for more flexible way, easier tool to build up my website with the technologies and structure that I would choose. I want to have full control of which layout engine I use, what kind of parameters I can have in my templates and so on.

I read a lot about different static generators and was thinking if any of these solutions were fit for my project. After some research, none of the popular and still maintained projects fitted my needs perfectly. I wanted a simple solution that was easy to modify and didn't include too many conventions. Many other developers had been on the same road and I stumbled on their blogs to read their thoughts. Of course my way of thinking doesn't fit bloggers without coding skills, because of the need to be ready to hack.

One promising static generator project was Metalsmith. It reminded me of task runners. So next I was looking into Node.js task runners Grunt and gulp.js. I've used all of these to build web applications and found out that many people were building their blogs with these tools. Developers have critisized the use of Grunt and gulp.js because of the lack of plugins for their needs or because of bad plugin implementations. After using these task runners, it is easy to notice that the task definitions and configurations can become bloated.

Sometimes the task runners are indeed too heavy solutions for a simple build process. There is the standard package manager npm that can also be used as a building tool through npm run commands. Not every library has a good executable, so with this solution you also end up writing executable 'plugin' files. One problem is that the shell commands need to be defined in JSON format that doesn't support commenting. Then there is the most oldschool way of building projects, make. Using make is similar to npm, but it works by defining a Makefile. Makefile is a configuration file that holds shell scripting that is used for building the project. Commenting is possible but we still need the executables for the used libraries.

After looking how many different commands and steps are needed to built my dream blog, I decided to use gulp.js. This seemed most reasonable choice for few reasons. Firstly, I need a way to pass data between the different phases of the build, so I rather have the flow inside one script file than trying to pass the data between executables. Secondly, all of the solutions need custom coding and with gulp.js I have the total control of the flow. Thirdly, my build process will have several steps because I'm trying to create optimized website and not just a simple blog. Lastly, I take this as a challenge to create a gulpfile that is not so bloated.

In the next post I'm defining goals, what kind of things the build script should handle, and how to tackle some of the problems that come up with gulp.js.