Creating This Site - Overview

  • Acuvic Websites
  • Sunday, Mar 3, 2019

A Little Background

So. The previous incarnation of this site was using WordPress with a site-builder plugin to speed up the creation process.

Then Gutenberg happened. We are pretty proficient at creating on the internet (since 2005) yet … Gutenberg crashed us out. It is a real train-crash! Simplest edits needed many keystrokes to achieve. Editing existing posts got locked up in “blocks” and adding to them became a big job of breaking up the blocks first. And as for changing images … forget it!

But the biggest fail happened to the previous version of this site ( The whole site vanished!!! Zilch, nothing left. We reasoned that the WordPress update must have clashed with the site-builder we were using. Gutenberg used “blocks”; the concept also used by our site-builder. Searching the forums only brought up firefights between pro and against Gutenberg. And fanboi’s galore telling all that Gutenberg is very easy and us “old skool” types need to modenise our out-dated ways of doing things! Then there were rumours (substantiated) that fanboi moderators were removing posts by anybody complaining about Gutenberg on forums. Then another of our WordPress sites broke due to plugin incompatibility with the Gutenberg update.

ENOUGH is enough already! We will abandon WordPress, at least for any new projects and gradually move all old projects away from WP. It’s time to move on.

New Era, Fresh Ways

Before updating this site, we explored the latest and greatest ways of achieving internet presence. Being in the business, we already heard of Static Site Generators and deployment from cloud (buzz-word warning: “serverless”). In fact, for proof of concept, we had a while ago loaded an old site built with vanilla HTML and CSS onto Netlify which was live and “serverless”.

Now, a few words of explanation as this post is aimed at those not too technical. WordPress generates the page only when a visitor lands on a page. It does this by running the content through PHP scripts and through theme and plugin settings. This obviously take time, hence we have to use caches to give the visitor an acceptable experience of our site. Static sites, however, already have the page fully generated and just need to push the contents straight to your browser. It is inherently faster and better for the visitor. And also better for Google who favour faster websites.

And “serverless” is a total misnomer. Servers are still there serving your website contents. Only that the web developer does not need to think of the mechanics of providing that server. Organisations like Netlify takes care of all that and we just create the website or app and connect it to Netlify to distribute. Another plus point of most serverless platforms are that they have physical servers sited all over the planet. So the whole world gets a faster experience of your website.

Enter The SSG

SSG = Static Site Generator. Of course static sites can be created using plain HTML, CSS and scripts. In 2005 when we started, we used a simple text editor and hand coded our websites. So SSGs makes this process easier and quicker, allegedly. In our search through various SSGs we found some that are very abstruse with steep learning curves that using plain HTML/CSS would have been preferable. And most of the internet reviews of SSGs are written by fellow geeks who loves the convoluted complexity of the methods used.

At this point in time, we needed to quickly put up a site for a group who wanted to see something in two weeks. And they had provided content already. WordPress?-no way Jose! We found a lesser known platform that did have good reviews from non-geeks. And a quick play with it and suddenly, the site was taking shape. This platform is called Publii. It is really a blogging platform, but have work-arounds to make it look like a “normal” website. As soon as we had a basic working local staging version, we pushed it to Netlify to deploy. And bang! it was up there, deployed and ahead of schedule. That was sweet.

But Publii did not fully match what we wanted to build the new acuvicwebsites. It was newish, so the web support forums did not yet answer all the essential questions. The existing templates being offered were very limited - we did not have time to create one at the moment either. And as a web presence company, we needed a platform that our potential customers have heard of. It has to feel as if the platform will exist for a good while and if needed, a replacement developer with required experience can be found.


In everyday reality of small/medium scale businesses, we don’t have the luxury of spending forever-and-a-day to choose our tools (or to “set up our stack”). We try out using something and if it “feels” good we push it further. We tried Jekyll, Eleventy and some others. Hugo was always on the shortlist because its lineage was the Go language developed by Google. And it promised a fast workflow - very important as it reduces developer frustration.

Like Publii, as soon as we started “hacking it”, this site started take shape. Very smoothly indeed. Ok, due to a bigger functionality, it took longer to scale the learning curve. But the community has existed longer and the answers to questions are like low hanging fruit. We were lucky to find a one-page theme that worked well. And also our previous WordPress site was a one-page wonder too. Hugo is also well supported by the existing serverless deploy companies.

Soon we had a basic site structure hammered out and decided to push it out through Google’s Firebase rather than Netlify. Netlify would have been easier, actually, due to its almost automatic support of form-mail for the “contact us” feature. Both also offered SSL (https) for sites it deployed. Firebase was chosen just because it was different. No big technical hu-ha was involved in the decision! Also Formspree was used for the form-mail function. With a minor Javascript email obfuscation and honeypot to reduce spam.

A point to note is that node.js and hence npm is needed to use Firebase, but it is a trivial process to install it. More of a challenge for GUI only users is that Firebase deploy is realised through the command-line interface. But this is a subjective difficulty - only a few simple commands are needed that are also well documented on the web.

So here we are! A modern new site that is Static and with an effective worldwide presence through Google edge servers.

  • A more technical post will follow detailing the nitty-gritty bits that went into the building of this website.

  • Actually, we are throwing open “post requests” to our readers. Any technology we have used can be the subject of the next post if enough people ask for it.