A New Homepage
2026/01/10 18:20
Long in the works, I've finally published the new version of my homepage. In this post I delve deeper into the why and how.
Prelude
I've had a personal webpage online in some form since 2009. Like many people around then, it started as a Wordpress page (under a subdomain at first, then to brunophilipe.com) which eventually evolved into a self-hosted installation (I think, memory is hazy). The first version archived by Archive.org dates to 2012. I have to say I still like that web design a lot (and it was clearly inspired at least in part by Windows Metro – wow remember that?) It also includes links to Google Plus (wow, remember that??) and to a Flight Simulator fansite I created back then, which was actually my very first website. I also built other fanpages in Wordpress, since they were free and easy to create (some are still up, but I won't link them here.) The Flight Simulator fansite didn't last long, but my homepage did. I've held to that domain ever since, but have since migrated to bruno.ph (which I gleefully called the greatest domain hack of my life when registered, back at the peak age of domain hacks).
Also like many people, I eventually got charmed by the idea of a simple static website, or at least something that doesn't require a backend like Wordpress. I started by building my own with a concoction of PHP scripts and json files, and that's what I used for many years. Again like many people, I eventually migrated to Jekyll.
The greatest difficulty for me when it comes to static websites is exactly what makes them so great: updating them can be non-trivial. You can run a local server to test and render your changes, then upload the results, but if you want to be able to update your website while on the go (for example using your phone or iPad), that becomes more difficult. You could also host a staging backend that you can use to test and render your changes, but I always dreaded having to do that. At some point, I go through 75% of a project to write my own implementation of Jekyll in Swift (an artifact of that can be found in the form of my LiquidKit library), but I never got through with that, as I dreaded the idea of having to keep up with changes to Jekyll when all I wanted was to maintain my own website.
So with Jekyll I stayed all these years. I learned some ruby and even wrote some custom plugins, but I never really got the hang of that programming language and all its backward statements, and so it remains a thing I dread maintaining.
PHP: The Return
PHP is the first programming language I ever learned – I did play with VB6 before that, but I didn't actually understand what I was doing at a very deep level. In the beginning I found its approachability similar to that of HTML, and since it lets you write as little code as you want in order to get started, that's what I did. I remember installing LAMP on my laptop and getting a website going in minutes. It felt mind-blowing to me that I was able to host a website (even if only locally) from my own computer. Suddenly, this technology which seemed mystical and out of reach – a portal I'd access – turned into a creative medium with endless possibilities that I could play with from my own laptop.
PHP is also the language that landed me my first full-time job, and I wrote it professionally for many years. And for all these reasons it's been my go-to language for anything web related. Even though it was a Jekyll website, my previous homepage still had many dynamic elements written in PHP.
As an aside, PHP gets (or at least used to get) lots of flak for being so "bad" in its loose type system and general clunkyness; however, I believe it to be objectively better than JS in all those regards, and yet JS is the darling of modern web development – and so I disregard those opinions completely. PHP is a capable and flexible language, built for a single purpose, and like any tool, if wielded properly, can work miracles.
That's why when I learned about Kirby, I was very intrigued. It mixes the best of both worlds: a static–ish website with a dynamic backend you can use to update it. It is "static-ish" because it uses PHP to render your content, but unlike Wordpress, it's not relying on a database service running in your server to render the pages – everything is stored in text files. This means it is very nimble and easy to deploy, while remaining very flexible and configurable.
In fact, that's the whole idea behind Kirby: you build your front end, and they provide the scaffolding and the backend. And so for someone who enjoys putting websites together (as in, the web-design side of things), I found this proposition irresistible, and for many months now I've been slowly putting this new website together, from scratch.
There's a little bit of PHP I brought over from the old website, such as the snippet that helps render the recent photos from my gallery on my homepage. I'll probably incorporate that code into the website's logic over time.
I enjoyed using Kirby very much so far. It's exactly the level of customization I want – but whereas on Jekyll customization led (me) to jank, on Kirby it's totally incorporated into the plugin/snippet system using the same language and APIs as the main CMS, making the website code a lot neater.
Kirby's flexibility made it very easy for me to code up new functionality on my website, such as the bookmarks page, which has a fully-loaded backend interface where I can create links and even create links that auto-redirect to the bookmark page, in effect creating my own link-shortener. I was also able to write my own control panel plugins that help me edit my content, including embedding content from my SmugMug photo gallery.
Kirby also has support for rendering draft content on the frontend, gated by access tokens, making it easy to try out things without worrying about how it will look, or risking making it public before it's ready by pushing to the wrong backend.
And last but not least, Kirby has a plain and honest payment model which lets you try the software and build your website for as long as you need, and only pay once you're ready to publish, which is excellent.
I'm still making changes to the website code and content, adjusting things here and there, but I'm very happy with what I have now and I'm excited to finally put it out there.
I was able to write routes to redirect all the previous URLs to new ones, and so none of the old website's URLs should become dead. This also includes the Atom (RSS) feed for the blog. I believe I got the new feed to match the previous feed's article IDs, so all previous articles should not appear as unread. That seems to have worked at least using NetNewsWire.
Conclusion
This is probably not the last time I make drastic changes to my website, but if the rate of reworking keeps its trend, it won't happen for another few (many) years. So I am very glad with what I've built! I think this will set me up for many more years, and look forward to writing new content for this homepage.
Thank you for reading, and long live the indie web!
Back…