Stop breaking my software
In August 2020 I published the latest version of my website, which is the one you are looking at. My goal is to never have a reason again to update it.
#Why I had to update my website
I might have never rewritten the software that runs my site, if I wasn’t basically forced to do it:
- My previous hosting provider decided to update their servers’ operating system and their libraries. I didn’t want to follow their migration guide and test if everything still works.
- The content management system I used had a new major version out for a while, so to stay up-to-date it would have required to rewrite big parts of my website’s code.
Although I’ve already tried to keep the previous version as simple as possible, the hosting provider and using a CMS turned out to be critical dependencies.
After all these years in this industry, I’m tired of every little unnecessary work that is required just to keep my website running. Therefore I asked myself the question:
#Will it run in 5 years?
If I had stayed with the DIY hosting provider by updating to their latest software version and had migrated to the latest version of Kirby CMS, that answer was: probably not.
Kirby is in version 3 now and has quite a few minor version updates during the year. Uberspace has been working on their new servers for a while and with new technologies coming up, it’s unlikely this’ll be the last major version of their system.
Therefore to make my site still work in five years I had to remove these dependencies. I’m back to writing markdown files again and the website is generated via my own ~130 LOC static site generator to HTML.
If vercel ever closes their business, it’s super easy to move my static HTML files to any other hosting provider that can serve them. With CommonMark having become Markdown’s official specification, breaking changes in the parser I’m using are very unlikely and could also be ignored, since the site generator will continue to work with an outdated parser too.
#The joy of long-term stability
Developers often praise how frequent their favorite tools receive updates and it’s common to celebrate big releases when they come out.
My expectation towards software is different. I want it to be stable and keep working as long as possible without any effort from anyone whatsoever. I should be able to come back to it 5 years later and still find it in a good shape instead of multiple major breaking versions behind.
This is yet another reason why Elm is great. Recently Evan even published a roadmap that says:
If you like what you see now, that’s pretty much what Elm is going to be for a while.
— Evan Czaplicki
Long-term stability is also the reason why Ember.js is used by huge companies like Apple, Netflix and Microsoft. Although being released in 2011 it’s still only on version 3. And when there was a breaking version, the team and the community spent a huge amount of time to make the migration path for projects in production as easy as possible.
Compare this to a React/Vue/Svelte… or any other JavaScript project being built right now. How confident are you that anyone can change it after 5 years? How much work will have piled up just to keep it up-to-date? How easy will the migration path be? My confidence in the long-term stability of these tools is very low based on the number of their breaking changes in the past.
There are enough changes coming in from clients, users and other developers, therefore I want the foundation of my software to be as stable and reliable as possible.