When I wrote about my move from Drupal to Hugo I didn’t provide details. This is an opinionated list of reasons I went with Hugo. TL;DR I don’t have time to maintain database server and web server. Static file hosting is cheaper. Hugo is self contained executable with no dependecies to worry about.
Shared hosting is too limiting
I hosted my Drupal sites on my own VPS instead of shared web hosting typically accessed through cPanel. I found shared hosts too limiting when I wanted to use Drupal command line tools such as Drush. I couldn’t install PHP modules used in custom Drupal modules that were not supported out of the box. Additionally I couldn’t install third party libraries such as PDF conversion libraries. Shared hosts are fine for users that stay on the well beaten path and I know a little too much to stay on this path. Besides shared hosting generally costs the same as a VPS in monthly fees.
Dedicated Drupal hosting is for businesses
I hosted my Drupal site on my own VPS as that is all I could afford. There are some great specialist dedicated Drupal hosts who take the pain out of maintaining your Drupal environment. Acquia, Pantheon and Omega8 are three such providers. If your business is dependant on your Drupal being up then you should use one such provider. At the time of writing the cheapest one was US$25 per month. A VPS costs me US$5 per month.
I am no sysadmin
There are some wonderful detailed guides on how to set up your VPS including DigitalOcean, Linode and HowtoForge. These sites also tend to have insightful comments that enrich the articles. These guides make setting a VPS fairly standard. The problem is when things don’t go as expected and you need a deeper understanding of Linux to resolve the issues. I have struggled in such instances and wasted days of my life trying to fix issues. Typical causes of such issues include:
- Using newer version of software than software in distro. Often newer versions of software come with game changing features or solve long standing bugs.
- Installing software that pulls in dependencies that have an impact on other installed software. Its easy to run command sudo apt-get install with unintended consequences.
- Sometimes you install software which is no longer maintained.
Setting up VPS is the easy part. The maintenance of the VPS is time consuming. You are never hundred percent sure that all software you install and all the upgrades you do will leave your system working well. It takes a long time to work through problems with server set ups.
I am no DBA
I am comfortable writing SQL. I do this for a living but I am by no means a DBA. I have a healthy respect for the folks who make sure our data is safe, backed up, vacuumed, optimised and always available. Setting up MariaDB and installing Drupal are simple enough. Like my reasons in section above it is when MariaDB does not start after a software upgrade that you need a DBA. It will take you hours to either fix the issue or setup a new VPS and restore your backups to the new server. Over time I realised it was easier to setup a new VPS and restore my back up files. Living in fear of something going wrong with my database is not ideal.
Hugo needs no environment set up
My route to Hugo was via PHP flat file content management systems since I already had PHP set-up for Drupal. I figured not having a database to maintain and not worrying about SQL injection attacks would be more manageable. I evaluated and found Grav to be a capable CMS. Yet I still found myself still maintaining a server. In the end I felt this was a half measure.
I wasn’t able to try out many static site generators because most needed to have an environment such as Ruby or Node installed. As much as I love learning new things, this whole post is about time. I don’t have the time to learn a new environment. This means I never did try out some of the more popular SSGs like Jekyll, Octopress and Middleman. Hugo is my favourite type of software. Download, add executable to classpath and you are in business. When you don’t want the software on your system, just delete the file.
HTML theming
In all my years using Drupal I only ever integrated two third party JavaScript libraries into my sites. Keep in mind I am not a front-end engineer and I use Drupal as a data platform. I found the learning curve to integrate a third party library the proper way too steep. I wasn’t keen on creating an insecure module. Thus I stuck to wonderful modules and themes developed by the Drupal community. This is not a bad thing, there are advantages to be said about safety in numbers.
With Hugo, theming is done in HTML files. I found making changes to themes easy. There are many good HTML and JavaScript snippets on the Internet by better developers than me that I can now use to enhance my web sites. No need for PHP knowledge, environment or custom module to incorporate these snippets. Using Hugo the process its a simple two step process:
- Copy the snippet into your theme folder
- Add Hugo variables to where you would like your content injected
You are still working in HTML. Feedback on the changes is quick. Hugo these do have functions for more advanced theming but getting started just needs HTML knowledge.
Disadvantages
SSG There are some drawbacks to using a SSG. There is a learning curve. SSGs are for people with a level of technical skill. You create content in text editor and view it in a browser. It takes some getting used. I have to depend on third party providers for comments and form processing. You have to set up mechanism to upload your “new” site every time you create new content. I use Stout to automate the process. This is still not as convenient as a CMS.
Conclusion
I am convinced most sites are not updated often enough to warrant using a full blown CMS. This has been my experience with the sites I have created for clients. Anecdotally I notice many CMS backed sites that have not been updated for years. All in all I am happy with Hugo. My posts are text files synced using OneDrive. I can use any editor to create and update content. I don’t have to be online to create content. In online discussions of SSGs I see that many proponents use Git for their text files. I don’t use Git often enough to use it efficiently in my workflow. Perhaps now that I am not constantly tinkering with my server I can actually get to do some writing.