New Site powered by Spress
For years this blog lay sleeping on the internet and I just couldn't get myself to work on content even though I had lots of ideas and opportunities. Part of the reason I guess was that the management of content never suited the iterative process I'm used to work in.
This site was first implemented with CMSMS and later with Anchor CMS. Though I tried to choose a solution as little complex as possible and got the basic layout and integration done with little effort, what was lacking all the time for me was the ability to have a 1-to-1 copy of the blog in my development environment. So I was hesitant to try things out and make little adjustments and wasn't able to have source control of everything I needed for this site.
During the last couple of years more and more information about static site generation crossed my attention and I was intrigued by the idea. I know there are many competitors but in quite a spontaneously act I browsed a small list of providers and choose the first one that looked promising. Because with no experience in the topic it's impossible to pick the right one.
So I gave Spress a try (http://spress.yosymfony.com/ , https://github.com/spress/spress).
Static site generation in general
Static site generation works in a way where you create your site in a development environment - this may be just plain files, an application or a whole CMS - and compile this into linked static HTML and asset files. Those files that browsers are great in displaying. There will be no database requests or backend requests for additional content. Everything that you see is baked into the file your browser downloads.
So what's so appealing about statically generated sites in general?
- They don't need cookies
All CMS that I have tried have some kind of user management. Even if you're only browsing the site it keeps track of your guest status saved in a cookie in your browser that is exchanged with every page within a site. As those cookies are often used for things the user is not aware of, the GDPR or DSGVO made the confirmation of cookie usage mandatory. This is a good thing but leads to those annoying popups and bars where you learn to blindly press Confirm. This site doesn't need one such thing. - No code injection
You don't have to be concerned about bots that browse buggy unmaintained sites, inject some code through a security hole and make it part of their remote controlled bot net. Because there can't be security holes in static HTML files. That also means you don't have to care for constantly updating your CMS.
Of course if someone steals your FTP credentials they could do this anyways but this is a completely different issue. - Easy backup, automat-able deployment and version control-able
As you compile the site every time you add some content you need to have everything necessary in one place.
With the CMS I worked with before I edited some style sheets in an in-browser editor that wrote to the filesystem while many other configurations as well as the posts went into the database while a separate media manager kept track of the images or downloadable files you added to the site. Knowing where what information resided was in-transparent and highly vendor specific. This made backing up all of this an unpleasant job. With site generation you can fully automate and theoretically even test the pages that are created while being able to have the whole site under version control with full transparency about what changes you make to content and design.
The last points were some things I consider general advantages but there are also points why this workflow suits this site and my personal preferences as well.
- I want to do simple things
There are no plans to make this page very big and technical. I guess if you have thousands of posts and want to apply tag filtering to your page the whole system will collapse. - I'm the single author
Even though with a shared repository and some trust in your colleagues you could have lots of contributors, at some point it makes more sense to use a CMS that brings user and group management with it. - No comments section
In the past when this blog had comments turned on it was only used by spam bots. Even though I'd like to have exchanges with readers I don't need the functionality in-site. You can always write an email to me if you like. That said the default theme for Spress even comes with working Disqus integration that moves the commenting stuff to a third party service. - Markdown
Markdown is the markup language used to write those posts. You define what should appear italicized or what should be a link. It's not as feature rich as your favourite word processor, especially working with tables is ugly, but for everything that is planed so far it is fully sufficient for my writing needs.
In contrast, I don't quite like how formatting in in-browser WYSIWYG editors work and how you always have to double-check if the correct span of characters has the correct styling applied. - I can use an editor of choice
As an extension of my dislike for in-browser editors I just enjoy having all files - be it Markdown, YAML, CSS, Twig templates - in a nice IDE (currently Visual Studio Code for this site) and have the appropriate syntax highlighting and linters available.
With this post I tried to show how this style of creating a web site has its own set of benefits. For me it worked very well. I never before had that much fun creating content for this site. In a following blog post I will go into specifics about how well Spress does as a site generator.