How and why this website was built
Last updated: 06 March 2024
Posted on: 02 March 2024
The Why
I used to host a WordPress site that acted as my blog. I used it to track my journey through the world of programming and game dev. I had many blog posts exploring many things that I've come across on my journey to be a better developer. When I started, the host I used was well-regarded. I used it and was happy with its service. The cost of the website was also pretty low, just a couple of euros a month. This changed when they were bought out. A month after the company was bought out, many of the links in their portal stopped working. Support had also seemed to disappear. In hindsight, this should have been the moment I moved off. I should have downloaded all the articles and moved to a different site. But I didn't.
A couple of weeks after this I lost access to the WordPress admin panel and many of the pages on my website stopped working. I tried support again but I still heard crickets back. It was only a couple of days later that the site went down. Again nothing from support. So I cancelled my subscription and tried my best with their limited tools to get as much of my website back. In the end, I got nothing. I got a couple of images but that was it. WaybackMachine and Google's Cache were also a bust. Contains only summaries of the posts, not the posts themselves.
I'd been floating around the idea of building my site from scratch for a while before these issues started. After this experience, I decided that I would host my site.
The What
This is just a simple blog. I don't need any magical auto-scaling like what Vercel or their competitors offer. I just need a little server that I can host the site on reliably. By trade, I'm a Backend Developer, though I fancy myself a Fullstack Developer. So wanting to be more full-stacky, I decided to go for a server-side rendering solution. This way I could still lean on my backend skills, but explore the frontend world "safely".
I started my search by just looking up full-stack, server-side rendering stacks. Trying to gauge what's out there. Learning a new programming language has never phased me, so it was more about the functionality of the stack, or the value of what I'm learning.
There's not a lot out there..... I spent days trying to find a proper stack that wasn't just "host both and use rest". Initially, I found this article on The JAMStack, which seems more like a loose collection of Javascript "stuff" than an actual stack. I also found this page about using React, but it seemed very complicated for what it does. It's worth noting that many of the large JS Frameworks have articles on how to do it with their frameworks, but it always seems like an afterthought or "host both and use rest" as mentioned above.
During this search, I noticed that almost every "How to build a blog full-stack" search links you back to React. This kinda feels weird to me. Why do we need this big Framework to develop something that is basically a static site? It feels overkill.
That's when The Primeagen started on his Go / HTMX arc. Here's one of his YouTube channels. It's worth taking a look, he's got plenty of knowledge to share, and it's pretty easy to find his HTMX videos. To give a short summary of HTMX here, HTMX is a JS (Javascript) library that lets you update specific parts of your web page using server-rendered HTML and attribute-based syntax. This means you can create fast and reactive web applications without needing to use a large framework. Visit their website linked above if you need a more in-depth explanation.
Though I really liked the look of his stack (I don't need anything complicated and magical for a simple blog), where I live, there's not a massive appetite for Go. Most jobs are looking for Python, with experience with the "new" kid on the block, FastAPI. So sadly the "value" isn't there yet for me to learn Go.
The best way to describe FastAPI is Flask with all the features you wish it had. It has some super useful features, such as auto OpenAPI spec creation and hosting with Swagger and Redoc, and a really simple but power dependency system for your endpoints. Based on this, I went for FastAPI + HTMX. I just needed a templating solution. This is an easy one. Jinja is the answer for most of your templating needs in Python. There are some cool-looking "up and coming" projects (in reality most have been around for a good few years now), like Mako with some cool new innovations. But in my case, I felt like Jinja would be good enough.
Now I just needed something to make the website "pretty". I needed a library that I can use in vanilla JS, and can easily use in my workflow. TailwindCSS was the answer. The decision was a simple one. It's an incredibly well-supported library, supports vanilla JS, and has a simple (but unofficial) pip install which includes all the basic features.
The How
The backend was surprisingly easy for me. I decided to use SQLAlchemy to have a simple database system for saving blog posts, saving users, and managing user tokens. This was pretty basic and you can find the models here.
I didn't want to write HTML for each of my posts, so I went with Markdown instead. This is basically why Markdown was invented, so it was an easy choice. Converting Markdown to HTML in Python is a one-liner thanks to mistune. I know there are alternatives out there, but this seems pretty well supported and does exactly what I need.
To easily update and add new blog posts I used the SQLAdmin admin panel. It's the only well-supported FastAPI/SQLAlchemy admin panel. I then added some custom admin views to add EasyMDE to the model views for the blog posts so that I can easily edit them if I need to make some simple changes.
Next comes the difficult bit. How do I make a pretty website? I've never been good at designing websites. They always look like they've come straight out of the nighties, and not in a good way like the Space Jam website. So I decided to try out Vercel's v0, and was sorely disappointed. Don't get me wrong, the websites that it produced were good, it was just taking way too long for it to output a site, and regularly broke on me. They also felt like they lacked the personal touch. For business websites they're perfect, but not for my blog. So I went with the image generator route. I spent a couple of hours arguing with ChatGPT to get a design that felt like a fun start.
I liked the combination of nature and tech in the image, so I ran with it. I think it's clear the inspiration I took, but I've tried to make it more lively, and a bit brighter. Using Tailwind here was a dream. I didn't run into many issues, and what I did run into was solved by just reading the docs.
You may have noticed though that my website isn't that reactive. And you're right. It isn't it's just a static site with templating handling all the dynamic stuff. I did use HTMX in one place. The Contact Me form. Having it there made it easy to manage what happens after you use the form and because of how HTMX is built, that's the only page I need to include the JS library, everywhere else is just plain HTML + Tailwind.
The Hosting
I went for Hetzner for the hosting. This was for a few simple reasons.
- I wanted to have a VPS that I could play around with. I have a few discord bots that I wanted to host as well without paying extra.
- They're based in Europe. I'm based in Europe so it makes sense to get something "more" local.
- The price is good. For what you get and all the features you can add, the price is really good.
- Though I don't use it, their Server Auction is sick and I want to support them because of it.
There are plenty of other good hosts of VPSs out there, feel free to use them, but this is good enough for me at a decent price.
Conclusion
On the back-end everything has kinda been the same as it has always been for the, just getting incrementally easier to build.
On the front-end, I learned a lot about the state of the modern web. It seems like there's such a push to use the big JS frameworks, there's not a lot of thinking about if you need them for your project. I'm not saying these frameworks are bad and we should abandon them for good old-fashioned 90s HTML. These tools have allowed the web to progress leaps and bounds and without them, the web would probably be a worse place. With that said, I think we need to make sure we use the right tool for the job. That will change from person to person, but maybe we should make sure we don't just default to a framework, and think through if we need a framework first.
And also Tailwind is cool. Give it a try if CSS hurts you like it does me.