Design Philosophy
I set out with some very specific goals when making this website, many of which are derived from values I wish to see on the wider internet.
Client-Agnostic
More and more, commercial websites are becoming reliant on advanced JavaScript frameworks that provide fun features like interesting animations, dynamic content, and full scale animations. On one level, the developments of browser technology over the past twenty-or-so years open up many opportunities. However, this has left us open to some drawbacks that many commercial providers have not carefully accounted for (or sometimes have intentionally ignored).
Sometimes, websites merely lack subtlety and just annoy users or give them headaches. Other times, it can make a website difficult or impossible to use. I have seen multiple websites that prioritize fancy effects over easy browsing in ways that interfere with load times, basic scrolling, and saving information (I just want to copy your fax number!). And of course, when some piece of JavaScript fails entirely (whether due to network failures, bugs, or aggressive security measures), the displayed website can be corrupted or just fail to display.
Security measures in particular reveal needless problems with many websites. With even the FBI recommending some sort of advertising blocking to deal with a rise in malware, businesses can no longer make assumptions about which third party domains will load. Nevertheless, sites like Amazon insist on pulling random domains on their pages, and most websites break if your browser is too aggressive in blocking Google dependencies.
This results in a varying degrees of poor experience for those not using bog-standard Google Chrome. Those using alternate browsers like Firefox are subject to various annoyances. Users coming in with RSS applications and screen readers often cannot view the content at all. And of course, very few websites even accept those of us using a graphic-less browser (server machine troubleshooting, anyone?).
As such, I designed this website to address those issues. The first is that JavaScript is completely optional. While there are a few cases where JavaScript does add some features that users may find helpful, the website on a whole is still viewable in cases where JavaScript is not available. Most of the processing is done on the server side, which is fully under my control. In the same spirit, I keep the HTML as clean as possible, so that even terminal browsers can view it without undue hardship.
User Respect
Over the past twenty years, I have watched as large players of Silicon Valley have created all-encompassing two-sides markets and then proceed to actively make the experience worse for all parties in the name of infinite growth. I wish to return to a more honorable time when a provider directly provides a service to a well-defined customer, and success was directly tied to user satisfaction.
As such, I resolve to keep my personal ventures fairly straightforward. If I provide something for free, users are free to view it without any strings attached. I do not need to know anything about who is viewing or downloading it. I do not make any demands on how they view it, download it, or share it. As long as they respect basic copyright (nothing on here is Creative Commons unless otherwise stated), I will treat them as rational, law-abiding adults.
For anything that is monetized, it will be paid for directly by the users. I do not subsidize anything from third parties. As such, I do not have any advertising partners, sponsors, or other entities that create any conflicts of interest. When I make something, the parameters are defined solely by myself and whoever I am making it for.
I also make a point not to pry. I will reserve the right to keep track of what IP addresses are contacting my server machine, but anything other information I collect is purely voluntarily and optional. I make a point to not arbitrarily hold features hostage for those who want to keep private, and I never send anything I collect to anyone else (one of the advantages of having no service providers!). I do not ask for anything I do not strictly need, and respect those who turn any such request down.
Handcrafted
For the longest time, webmaster had templates, website builders, web hosts, and other such tools to facilitate getting their thoughts online without having to worry about the underlying engineering difficulties. With the rise of Large Language Models trained on GitHub and Stack Overflow, modern webmasters have even more tools to simplify not just deployment, but even the creation process itself.
I generally do not have a problem with third-party backends, and I am not entirely opposed to using AI in the right use-cases. However, one goal I had for this website in particular is something that I can unquestionably call "mine." I want something that I can declare as personally made by me, without having to rely on the skills of others. As such, I abandoned all pre-existing templates, engines, and providers. This website is running off of a PHP engine I created from the ground up. With the exception of some public domain icons, three small libraries, and standard Docker images, everything that runs this website was developed by me personally. The blog is running off of a custom NodeJS application I wrote myself. The account engine, while utilizing the standard OpenLDAP system, is using logic and a schema I developed specifically for this website. The contact icons aside, every image was made by me. Most of it was written not with IDEs, but with the GNU Emacs text editor. While some of the tools are third-party integrations, I can point to the main site and declare it as "mine." I did not contract anyone, and I did not have AI write even a single line.
Of course, this is not something I will hold for everything I do, especially for-hire or contract work. I will use whatever tools are needed or requested when making something for someone else. Nevertheless, this site is my own.
Dependency-Lite
After spending a few years in both the industry and in open-source, I have seen a pattern where most projects will have massive dependency requests, and rely on a large number of third-party services to run. Now, while there is value in utilizing what other people have made. It helps us to save time and progress at exponential rates. Man cannot progress in any venture if He is forced to reinvent the wheel at every juncture.
However, there can be a tradeoff with this approach. History has demonstrated that software is fragile, and even innocent changes from one party can completely break any number of things in projects that first maintainer does not even know about. In time, all software will stop running on modern systems. Often, it is merely a result of core operating systems or even CPU architecture changing. Those are difficult to work around. However, the more additional dependencies one adds to the project, the more potential points of failure are introduced. As many of these dependencies have dependencies of their own, and at minimum will depend on standard libraries and the operating system in their own unique ways, the weak points of a piece of software can increase exponentially.
This is even more of a concern when the dependencies are constant-deployment network services. Trying to get information between different machines has always been a difficult task that relies on rather strict rules between both machines. Any time something changes (and providers like Google will change things a lot), the communication breaks down. It gets even worse when your dependencies just stop working, as what rather infamously with CrowdStrike in 2024, or to GitHub a rather comical number of times in 2026 (the uptime graph does not tell the whole story).
The situation can even become dangerous. The year 2026 along has been marked by multiple high-profile supply-chain attacks where trusted vendors were infiltrated by malicious actors, and the customers paid the price. Supply-chain attacks are extremely difficult to protect against, and the attack surface again expands exponentially with the number of dependencies.
As such, I am working to keep my work more self-contained. At the moment, the website relies on three main libraries: ramsey/uuid to process UUIDs (which I am shocked is not part of PHP's standard library), PHPMailer to facilitate SMTP connections for emails, and Pandoc to handle file conversions. By keeping the number of dependencies I pull to a minimum, I can reduce a variety of painpoints in development on differing machines, deploying, and maintaining.
This is one of my more recent design guidelines, so there is room for improvement. I am still relying on several Docker images and the Ubuntu repositories, so outages in either of those will interrupt new deployments. However, I have further goals of consolidating build images to my own servers to reduce the number of external connections I need. I am also preparing to move away from downloading pre-built binaries and instead relying on building dependency source code from within projects, so I do not need to rely on third-party repositories. If the software world burns, I hope to keep my own work available.