Everything Old Is public_html Again

Margin marks

Failure 1Decision 1Workflow 1Principle 1

4 human-approved annotations, anchored to the article text.

A few months ago, I published a very long article about rebuilding this portfolio with AI, static HTML, and stubborn taste.

A lot of that article was also written with AI, which may explain why we made the same point seven times (still rebuilding some trust in the writing department). The basic argument was sound: we excavated my old portfolio from a swamp of downloaded themes, repeated HTML, CSS overrides, abandoned folders, and other load-bearing ghosts (¯\_(ツ)_/¯). We preserved the eccentric bits and made the machinery of maintenance considerably less painful.

Then we deployed it to Firebase.

Now we have moved it again. The new version is running on the fancy new Railway, a fully managed cloud PaaS (Platform-as-a-Service). This feels like a good time to revisit some of my earlier technical decisions and publicly apologize for at least one of them.

Specifically, the decision to place as many as 30 GIFs on a single page.

My reasoning was that motion work should move. Representing animation with a static thumbnail feels like pinning a butterfly to a spreading board. Technically, you can see it. But you've removed a lot of what makes it interesting.

I still believe this. Unfortunately, I expressed that belief by making your browser download the Library of Congress.

The resulting load times were horrific. This was not Firebase's fault. It was not a problem with the build system. No hosting platform can protect a grown man from his own artistic convictions.

The principle may have been defensible. The implementation was a misdemeanor.

The GIFs are still here, because apparently I am capable of remorse but not reform. They no longer arrive as GIFs, exactly. The build now generates a lightweight WebP poster and interaction-loaded WebM and MP4 versions. The work still moves; your browser simply no longer has to download an independent film festival before viewing a project page.

That brings us back to hosting.

Firebase felt genuinely futuristic when I first started using it. You could deploy a site from the command line, connect a custom domain, get SSL automatically, and serve everything through a global CDN. It had preview channels. You could test a release and then promote that exact version into production. Firebase still does all of this, and none of it is objectively bad.

But in hindsight, Firebase kind of sucks for this website.

Firebase belongs to a much larger universe of databases, authentication, functions, application services, billing plans, project identifiers, deployment targets, and miscellaneous Google Cloud machinery. That is all useful if you need it.

I just needed somewhere to put some HTML.

Using Firebase for a static portfolio increasingly felt like obtaining a municipal building permit to hang a picture frame. Nothing was exactly broken. It was simply far more platform than the site required, and every visit to the console carried the risk that I might accidentally create an enterprise identity principal.

Railway is part of a newer generation of hosting platforms built around a much shorter instruction: Give us the repository.

Railway connects to GitHub, builds the container, runs the site, and produces a working deployment. When I push a change, it can build and deploy that too. It supplies a temporary domain, handles SSL, supports custom domains, and provides previews without requiring me to perform the old Firebase ceremony of deploying to one target and cloning it to another.

Railway calls this zero-configuration static hosting. My version required a GitHub connection, a two-stage Dockerfile, a Railway configuration file, a custom static server, and several DNS records, so “zero configuration” remains one of the tech industry’s more spiritually aspirational phrases.

What I like about Railway is that the same basic experience also works for actual applications, databases, background workers, and whatever questionable project I decide to build next. The portfolio remains a static site, but it now lives on the same general kind of platform I use for far more complicated projects.

Simple website hosting is in an odd place now. The infrastructure underneath it has become incomprehensibly sophisticated, while the experience on top has slowly circled back to:

Put the files in the place.

GitHub Pages, Cloudflare Pages, Netlify, Vercel, and Railway all offer some version of the same arrangement. Connect a repository. Tell the platform how to build the site. Tell it where the finished files are. Point a domain at it. Wait for the internet to notice.

Conceptually, this is not terribly different from what I was doing on AngelFire more than 25 years ago.

You built a page with AngelFire's god-awful CMS, then you clicked (not tapped) the Publish button. That was the architecture.

Later, there was cPanel, FTP, and the sacred public_html directory. You could see the files. You knew where the website was. If index.html stopped working, it was usually because you had one-too-many and modified index.html last night. There was a certain dignity in the clarity.

Those systems were not better. Websites did less, expectations were lower, security was largely theoretical, and half the internet consisted of an animated "UNDER CONSTRUCTION" sign besides a guestbook. It was a simpler time for simpler people.

Today the folder is a Git repository. FTP has become an automated deployment pipeline. The server may be a container assembled by software you have never seen. SSL certificates appear automatically. Every change can receive its own preview URL. Somewhere behind the friendly interface, an orchestration system is making hundreds of decisions so I can continue pretending I merely uploaded some files.

The move to Railway has not changed the architecture of the portfolio (though I did overhaul the CMS). It is still structured content passed through shared templates and generated into static HTML. The public site still has no database, no authentication system, and no exposed content-management backend.

It also still moves.

The GIFs survived because they are part of the visual language, and stubborn taste has apparently survived another migration. The next challenge is learning the difference between preserving a creative decision and forcing everyone else to suffer for it.

Twenty-five years after AngelFire, website hosting has successfully reinvented uploading a folder – except the folder is a repository, the upload is a deployment pipeline, and the little train provisions its own SSL certificate.

Progress, I suppose.

All aboard. 🚂