On Building Software

Old School Workarounds: The Interstitial State

I feel fortunate to have been working on the web (as we know it) since its infancy, which I’ll consider to be the late 1990s. Long before Typescript, JS frameworks, and web containers, when web development was flat files and FTP. When even using Javascript was for the fancy-pants crowd.

Occasionally — whether by nostalgia, practicality, or boredom — I will still do a very Web 1.0 thing. And when I do, I can’t help but smirk. It’s like turning the key inside a car sitting in the garage for a dozen years and hearing the engine hum with ease. Satisfying.

I’ve done it twice fairly recently in DoneDone and so the act now moves from happenstance to pattern: The interstitial screen pattern, I’ll call it.

The pattern is to mimic the feel of a single-page app (enough) while still keeping true to the old school “full-page refresh” POST paradigm. You’ll recall back in the day when the internet did all of its processing with an embossed button click, a scratch of the chin, and a long awaited refresh of the same page, yes?

Back then, we were conditioned to wait — we knew to wait. And we knew that if we closed the browser or otherwise manipulated the page while it was making its return trip during a POST, something strange might happen and it was our fault for being impatient. So we waited patiently.

Of course, that’s not as true now. When the button is clicked, we expect to see the visual cues that processes are happening, lest we think we didn’t actually click on the button. We also expect the “page” to remain as is with only the requisite parts changing, so it feels like an app and not a bunch of random files.

In the places in DoneDone where I don’t have a SPA framework set up and I am using old school pages, I can have my cake and eat it too by introducing the interstitial state: The state between the click and the full-page refresh.

I’ve done this in a couple of different ways.

When a user updates their credit card information through Stripe’s checkout UI, Stripe should redirect back to the billing page on our side — except that the billing page usually takes a few seconds to load because it requires some calls back to Stripe.

So instead, I have Stripe redirect to an interstitial page showing a CSS loading animation while it’s waiting for the response.

The interstitial calls a redirect to the slower billing page via old reliable window.location.href and once the slow page response has completed it’s rendered.

In DoneDone’s back-office admin tool, we manage feature gates via toggle buttons on the account detail page. When you click on a button, the POST leads to a refresh of the entire page — which again, will take a few seconds to load.

So while you’re waiting, a full-page div immediately surfaces on click (via, in this case, manipulating the div’s visibility with JS) while the full-page POST refresh executes.

Of course, it naturally goes away when the page has refreshed.

With modern speeds this actually has the feel of a snappy SPA app, unlike the really old days where pages had to spend noticeable time rendering. Layered on top of current speeds, you get the effect of SPA with some old school implementations using the most basic in-page Javascript.

A fun blast from the past that is simple and still good enough.