The technology that runs the site

The technology that runs the site
Photo by Markus Spiske / Unsplash

After finding the motivation to build my own website as discussed in the previous post, I had two main areas to focus on:

  • planning the content to share
  • choose the technology to use as a foundation for the website

On the content side I started brainstorming some possible ideas for articles and posts, sketched a few concepts for tutorials and projects to show the tools and techniques I use everyday and so on. But before I can share any content I need a platform on which to share it.

On the technology side I know I'm starting from scratch and with an audience to build, so investing money before even knowing if someone could be interested in what I'm creating can be both good and bad at the same time. It could be good because it would push me to create content regularly and to share more ideas. But it could also be bad because rushing, especially in the beginnings when I'm new in this world of content creation, could mean throwing away money (even if we are talking about a risible amount) and creating bad content. Which would lead to a dead end very quickly.

I have a few requirements to focus on. To start I'm looking for:

  • a content plaform easy to maintain so that I can spend more time creating and less doing maintenance on the platform itself
  • a tool with an easy to use editor, possibly a WYSIWYG one, to help me visualize the output while writing
  • a platform that can start small and scale up or out to the need
  • something based on a recent technological stack and that is of course mobile first and that can be customized and extended
  • but most of all, a techonogy to create the fastest possible webiste, since I don't like slow things

Which platform for a new website in 2022?

With these requirements in mind I started looking around for possible candidates, considering both cloud services and on premise solutions, without discarding the possibility to build something myself as a side project.

After a brief investigation online I restricted the choice to the following three options:

  • Wordpress - it is as old as the blog concept itself, written in PHP, it is a sort of de facto standard for building small sites and blogs, and it is the straight choice for beginners, or at least it was a few years ago. It is available as a SaaS solution or self hosted, and there are even plenty of hosting services that support Wordpress at almost every price range. Fast, Secure Managed WordPress Hosting
Create a free website or build a blog with ease on Dozens of free, customizable, mobile-ready designs and themes. Free hosting and support.
  • Medium - an interesting SaaS solution that allows to start for free and to grow with membership options. A lot of blogs both personal and corporate ones are hosted on Medium and it can be an easy platform to start with.
Medium – Where good ideas find you.
Medium is an open platform where readers find dynamic thinking, and where expert and undiscovered voices can share their writing on any topic.
  • Ghost - a more recent project, based on Node JS and available in SaaS or self hosted, basically similar to Wordpress in features but more interesting on the technical side as I'm already working with Javascript and node.js tools on a daily basis.
Ghost: Turn your audience into a business
The world’s most popular modern publishing platform for creating a new media platform. Used by Apple, SkyNews, Buffer, OpenAI, and thousands more.

Long story short, after a quick comparison and after reading a few reviews of the three options, my choice was Ghost. The cloud service is very interesting and reasonably priced, but... since I'm a Software Engineer I wanted to play with the tool myself and dirt my hands building something on top of it instead of just subscribing to the cloud service and choosing a nice theme.

To be honest there was also a fourth option that was to use a headless CMS to host the content and build the entire frontend on top of it as a React application, but I temporarily discarded it to shorten the time required to build the website (not really discarded because Ghost can also serve as a headless CMS as I will discuss in a moment).

To keep things small but with a bit of customization, I opted to make a static site from the content coming from Ghost, so I had to choose how to transform the Ghost frontend to a static site that is FAST, but also nice and clean. The options were:

  • Next.js - The React framework to build static and dynamic sites with all the features you can imagine and with impressive speed.
  • Gatsby - a framework to build static and dynamic sites taking content from a headless CMS or other sources. The resulting site has impressive performance and the optimizations applied to images are among the best possible.
  • Fried Chicken's Ghost Static Site Generator - a tool that basically crawls the Ghost site and generate a static version of it replacing URLs and optimizing images.


Next.js by Vercel - The React Framework
Production grade React applications that scale. The world’s leading companies use Next.js by Vercel to build static and dynamic websites and web applications.

I started playing with Next as my first option since taking content from Ghost and serving on a customized React frontend is pretty straightforward and you can get a working prototype in a matter of hours or even minutes if you already know the framework itself.

The first prototype was working pretty well and it was fast since the build task generated all the static pages upfront, ready to be served by a web server. But there was still something I didn't like: the optimized images plugin requires that the app is served from a running Next instance, so not that static anymore.

This requires a hosting supporting Node.js and makes part of the efforts of building the static version of the content upfront useless. Sure, Vercel (the company behind Next) has a cloud service to host Next (and other frameworks) on an optimized platform with a dedicated CDN (Content Delivery Network) and all the usual things you want for a top quality service, but this means that I also need to serve Ghost on a public service to let the image optimizer get the original content.

Instead of having to serve Ghost alone now I have two different services to manage... red light. This surely is a nice option for a bigger project, maybe for a big client, but for my little tiny newborn website is an overkill.


The Fastest Frontend Framework for Headless CMS’s
Gatsby is a React-based open source framework with performance, scalability and security built-in. Collaborate, build and deploy 1000x faster with Gatsby Cloud.

I already played with Gatsby a few months ago for a proof of concept project of a headless e-commerce platform (more about that on another post), and I loved it, so building a prototype with it should not be that difficult.

I started again with a new Gatsby project, added the Ghost source (there is an official plugin for that) and played a littte bit with the theme.  Again, in a matter of a few hours I had a working prototype with a nice looking theme and the content served from Ghost. This time the build also generated every possible optimized version of every image so that it can be served in the most appropriate variant for each client. That means that the same image could be served as a jpg, png, webp or other format depending on the browser the user is using. Sure a top feature to get the best speed results, with the only drawback of taking up more disk space, but this is not a problem for me due to the fact that the site is very small at this stage.

I was quite impressed by the prototype performance and quality but... the internal links inside a Ghost post still refers to the Ghost URL, and the HTML structure of the content is deeply linked to the CSS classes of the Ghost content blocks. To be clear this is not a bug or a Gatsby defect (and also Next has the same problem), it is related to the Ghost API and its data structure.

The URL problem is not a difficult one to solve, since there is another plugin to handle this and rewrite to the correct addresses, but the HTML structure and CSS classes require me to rewrite the entire Ghost theme inside Gatsby. This is a one-time task, ok, but maybe it can create problems with future updates of Ghost and it also has the side effect of generating two different outputs of the same content, the Ghost preview based on the Ghost theme in use, and the final output based on the website styles.

We were so close to the target...

Using Gatsby is still an option but it requires more effort than expected for now, so yellow light, lets see if there is another option left.

Fried Chicken's Ghost Static Site Generator

GitHub - Fried-Chicken/ghost-static-site-generator: Generate a static site from ghost and deploy using a CI
Generate a static site from ghost and deploy using a CI - GitHub - Fried-Chicken/ghost-static-site-generator: Generate a static site from ghost and deploy using a CI

Ok, so lets try to keep it even simple and start with the easiest possible solution, we'll build a static version of the Ghost site using the Ghost Static Site Generator (gssg) open source tool.

gssg is a node.js command line utility that uses wget to save all the pages it can reach from the home URL of your Ghost site and process every page with some filters to replace urls and optimize images and dependencies. In its simplicity it does what it promises, that is, it generates a static version of the Ghost site inside a local folder that can be uploaded to your preferred hosting service and be served without external dependencies.

Since it does what I need, to get started with this site it is the easiest tool to use and the quickest solution to my needs, so... green light on it!

Next steps

Now that I have all that I need to get started, the next step is to start making content to share with you, so see you soon with the next article and if you want to get in touch with me, have a look at the contact page on how to contact me.