I have always had an intense dislike of over-complex web frameworks, even before I had ever heard the term "web framework". In 1995, when I was in sixth grade, I "went online" for the first time, and I immediately knew I wanted a webpage of my own. At that time, GeoCities was the best thing for this, so that's what I did. A few iterations later and I wanted more control, less "framework": I moved my website from the cesspit of animated GIFs that was GeoCities to the now forgotten Simplenet, because Simplenet was, well, simpler. And where GeoCities only offered pre-built tools, SimpleNet instead included (for free!) a website scripting technology called Miva.

In the long and ever-changing topology of web technologies, Miva is not now and never has been a major player. Originally called HTMLscript before a 1998 rebranding, the environment is now marketed as a off-the-shelf custom shopping cart for your internet store. The part that I care about, Miva's custom scripting module "Empresa", continues to exist into 2019 only because of a group of small, insane people such as myself. I know more about the history of the Miva programming language than anyone cares about, and at some point I should learn some other programming language as well as I know Miva, but that day is not today.

My personal website when I was 15 years old in 1998

Having had a personal website basically all my life, the skills learnt from this have meant that I've usually found myself running websites for organizations I work with, since I tend to think that no matter what problems we're facing, they can be solved with websites. To run those websites, I've used all sorts of tools, made by all sorts of people; I haven't counted, but I estimate that I've used over one hundred hyperbillion different website making tools. Some tools were specifically for making websites, some made web pages as part of a larger solution. But what all megakerjillion had in common is that, I hated them. I hated their restrictions. I hated their caveats.

Website I made for a club in 1999. This is what the web used to look like.

Using frameworks, I could not make the websites look and work the way I wanted them to look and work. For my personal sites, other people's tools always cluttered up the pages with stuff I didn't want. For an organization's website, the organization always requested some feature that I knew was programmatically possible, but the framework was incapable of. Now, this isn't to say that I'm a great web designer or gifted programmer. I think I'm just OK at both, and am probably being generous in that assessment. But I build websites anyway, because I'm happy with what I'm able to achieve, and organizations mostly are, too.

From 2001 and pieced together using Photoshop and HTML tables, I now feel weirdly compelled to re-create this using modern CSS

And it's not just that I've eschewed complete package frameworks, either. Every attempt to try a trendy technology such as Jquery or Bootstrap or SCSS has made me similarly frustrated. Those tools just end up adding a lot of bloat to sites – creating complex dependencies which make for long page load times at little to no gain.

This is all a roundabout way of explaining why I have used a pre-historic technology stack to create my own program to achieve a result that thousands of others already have. Altogether, my bespoke tool runs what today are called "minimalist" websites – for instance, with this site: under 100kb transferred (which includes the photo file for self-portrait) and load times in a few hundred milliseconds – even though minimalism was never the goal: creating a useful website was.

By 2004 I was making some sort of... whatever you call this

Why "Tranquility"?

So, about Tranquility itself. Why call it "Tranquility"? It's complicated.

The first time I ever wrote scripts to dynamically manage content on a website (back before I knew that I would be working on those same scripts for over two decades) I didn't know how to do user authentication, so instead I put all the scripts in a folder with a name I thought nobody would ever guess: "dogbert". When those scripts finally congealed into a program, in my head I was calling it "dogbert version 2", but on some level I knew that name was dumb. And so was born the first iteration of this program: "dv2".

In preparing to write this article, I pulled up my old source code from back then, and it's almost as embarrassing as the websites I created using it. The latest timestamps I can find on files from this era are October 2004, and the earliest are June 1999. The original website it drove was a friend's project called "Ibutsu", but after Ibutsu shut down in May 2000, I used the scripts to create an overly-complex personal website.

Ibutsu, from 20 years ago

dv2 could only ever drive one website – it wasn't portable, it couldn't install itself, the program without its data tables was worthless. But it did have rudimentary dynamic content, and lots of precursors to features that we now call "social media": forums, chat rooms, polls, user profiles, news tickers, user generated content. True, these features sat upon an insecure, bug-laden, spaghetti code mess, but that didn't stop us back then.

What dv2 looked like

I should make clear, these major versions I'm delineating in this article are something I'm arbitrarily deciding now, not what I understood to be undertaking at the time I scripted them. Back then, when I learned a new technique or concept, I wouldn't rewrite old code using it very often. But the occasional full re-writes are guiding how I'm categorizing things now.

The second major stopping point on the path towards Tranquility was a script collection that I called the "engine", because it was the engine that drove websites. In the era of engine, I had many script collections, one for each website I was running. Digging through my old files, I've re-discovered many projects I've worked on, some large and functioning, some insignificant and incomplete (including one amusingly-named project "Pax Discoteca"). For each, I created a separate collection of scripts to power it, with lots of code sharing between them. This largest collection, "engine", was for the fandom convention AOD.

One of those cool source code screenshots

Many of the scripts I created for AOD were useful only for conventions: attendee registration, event planning, schedule making. But the code quality itself is what really began to grow. For the first time, I was writing web apps that a large group of people were using in a serious way. By necessity, I was re-writing old scripts and creating new with best-practices in mind, running test instances before putting things in production, thoroughly ironing out bugs, considering all edge cases, and dealing with feature requests. Even though I've since abandoned those convention-specific scripts, the techniques and tricks I learned from making them live on.

Melissa Louie's 2013 "Harmony" website layout for AOD

What I saw working on AOD and other projects, is that no matter how varied the purpose of the website, they tended to fit into similar patterns. No matter what the project was, the website needed a tweak-able layout, a blog or newsfeed of some kind, a "contact us" form, et cetera. Sure, the bimbly bobs were different, but I envisioned a system where every website ran the same software, software that made every feature available, no matter how single-use. Then those features could simply be enabled or disabled as appropriate for the website in question.

And so in 2012 grew the third major iteration, imaginatively called "Site Tools". The bland name may not much inspire, but the goal of Site Tools was grand: throw a complete "Site Tools" program onto a Miva-enabled webshare and watch as it effortlessly installs itself, automatically creating all its data tables and placeholder files. Then you login, set up the modules you need, customize everything to your heart's content, and now you've got yourself a website!

I actually did this. I finished it, it existed! It was all up and working. I even published a few compiled versions you could have downloaded.

The Site Tools dashboard

So what happened? Why am I not talking about how the Brandenblog is powered by Site Tools? Well, a problem crept up from a direction I hadn't expected: upgrades. You see, when is a web app ever, truly completed? Never, that's when. There's always something that can be improved, upgraded, streamlined. And maintaining 10+ different instances of Site Tools, and updating each of them each time I made a change, and when that failed, keeping track of which version each was on, well all that was the death of Site Tools. But for eight glorious years Site Tools ran websites.

Eventually, I found myself abandoning a major revision of Site Tools in lieu of going back to creating bespoke one-off scripts to power each website I was making. I knew I had come up with a better answer. And from this seed, grew Tranquility.

A 2017 non-Site Tools website I ran

Why "Tranquility"?

Why call it "Tranquility"? First off, with a legacy of names like "dv2" and "engine" and "Site Tools" I sorely wanted a real name to call this project, something that's still descriptive, but in a more ethereal way.

So, why "Tranquility"? There's levels. On one level, I like the idea of being tranquil, at peace. I desire more tranquility in my life.

On another level, one of my favorite Magic: The Gathering cards as a teenager was called "Tranquility". I still remember it, and that despite its peaceful name, Tranquility was a card that used peace in a destructive way, removing all enchantments from play. The concept of tranquility as a source of power struck a chord, to the depth I still remember it today, 20 years since I've played the game. So when naming this web app, I liked the concept of this M:TG Tranquility card, and I liked the reference to my teenage years, where some of these scripts have their roots.

And on a third level, I am now and always have been fascinated by space travel. When humanity first walked on the surface of another planet, we called the place Tranquility Base, since that place was in a basin called the Sea of Tranquility. I love being able to reference this, and call the dashboard of my web app Tranquility "Base" as a nod.

Tranquility even lets the user pick their Tranquility color scheme, the most useful feature

Now that we understand the name, if Site Tools already did everything a website needs, what makes Tranquility better than Site Tools? Well, as I said, no code is perfect. So to start, Tranquility includes a complete code refresh, every single line of every single script reviewed and updated. This alone resulted in many new features, many bug fixes, many efficiency improvements, and many workflow standardizations. This was significant, but major version significant? Probably not.

The major version-worthy change comes from the idea that only one instance of Tranquility need run – that one instance of one program could run every single website. This goal is easy to articulate in words, but difficult to pull off in script. How do you securely let one webshare control what happens in another? How do you guarantee content and material from one website never can appear on another? How do you seamlessly manage software upgrades across all sites at once? The challenges of making Tranquility so fully dynamic dwarfed the effort of modularizing and re-writing the scripts.

Tranquility Base in all its glory

Done but not Complete

Tranquility is done, but it isn't complete. It is working, functional, and meeting my goals for it. But as always, improvements are planned. To keep perspective, it is important to take this step back and survey how far I've come.

Is Tranquility ready for the public? Honestly, I'm scared to show others my baby, but I know I must. The few people who have a website hosted by me will be using Tranquility soon, and I always welcome others to join if they want hosting Branden-style. But I know that on an internet filled with ways for anyone to make their own website, I will always be my own main customer. I have fun doing this, and am proud of my achievement.