I've been a sucker for Common Lisp ever since I learned it. When I started the blog, I chose to use Coleslaw, a static blog generator written using the language. It worked great for writing blogposts really, but when I started migrating my complete online presence here, it suddenly felt like an unnecessary constraint. I wanted to be able to customize the experience, create private areas of the website, obtain full control. This is also known as the Lisp Curse - even if Coleslaw might have supported everything I needed, possibly with some tweaking, it was hard to not fantasize about basing the site on my own blogging solution. Knowing about the curse, I counterintuitively tried ignoring Lisp, and decided to build functionality piece by piece, using tools most appropriate for the task at hand. In the case of OpenID Connect integration I used Python, as good libraries were already available, and that worked fine for a while. I was writing more, and it seemed that I had control. But then I hit a bump in the road. In the interest of speed and developing the blog in the leanest way possible, I appended every post to one same HTML file. Blasphemy, right, but I'm glad I did it because that helped me write quick and write a lot. When it was time to split the posts into individual files, I naively assumed that HTML5 would come to rescue, because surely there would be a way to import pages by now. There is and there isn't. So now I had to decide if I would resort back to using a static site generator, if I would start using a standard platform like Wordpress, or write my own thing. Obviously, I decided on the latter.

What you are seeing now is rendered through semistatic, two hundred lines of code for something in between a static site generator and standard blogging software. I'm going to try to stabilize it a little in the coming days before putting it online, but here's what I tried designing for:

1. I should still be able to write standard HTML pages for my blog posts. If it turns out I want to create a post with non-standard structure - a microsite really - it should come with zero overhead.
2. In the unlikely event any of the posts I write becomes popular, semistatic should be smart enough to route the viewers to the original static version.
3. The software should be smart enough to do the basic things that the static generators do: aggregate pages, create feeds, group posts by tags. It should also be able to resize images, apply common styling, and in general work seamlessly with static data without using any special syntax. It should support transforming posts in any way imaginable. Syntax highlighting, math formulas - which Coleslaw can do by the way.
4. Where it gets interesting is that I want to support functionality that has to be backed by a dynamic service. If I want to restrict access to certain posts as before - that should be possible as well. If I want to show how many people are viewing the post at the same time, if I want to support Medium-style highlights, ActivityPub - that too.

Exciting, right? Let's find out how bad of an idea this was while I continue migrating stuff.