Building websites with lots of little HTML pages

Old school web tech is the best. I still reach for multipart/form-data every day. Many of my web applications do not even have javascript.

I hope at some point the original pattern is re-discovered and made popular again because it would make things so much snappier:

1. Initial GET request from user's browser against index and maybe favicon.

2. Server provides static/dynamic HTML document w/ optional JS, all based upon any session state. In rare cases, JS is required for functionality (camera, microphone, etc.), but usually is just to enhance the UX around the document.

3. User clicks something. This POSTs the form to the server. The server takes the form elements, handles the request, and then as part of the same context returns the updated state as a new HTML document in the POST response body.

4. That's it. The web browser, if it is standards compliant, will then render the resulting response as the current document and the process repeats.

All of this can happen in a single round trip. Latency is NOT a viable argument against using form submissions. I don't think suffering window navigation events is a valid one either. At some point, that SPA will need to talk to the mothership. The longer it's been disconnected, the more likely it's gonna have a bad time.

The web only has to be hard if you want to make it hard. Arguments against this approach always sound resume-driven more than customer-driven. I bet you would find some incredibly shocking statistics regarding the % of developers who are currently even aware of this path.

I'm doing something sort of similar now -- my research advisor was remarking on the messy state of all the scripts I use for numerical experiments (there's dozens of them, poorly commented, constantly changing and not well versioned, assumptions/purpose not documented etc).

Naturally I used that as an excuse to implement a framework for tracking the output of numerical experiments along with any generated assets and output and configuration details in a SQLite database. Then wrote a generator that pulls everything out of the database and builds a static HTML site.

Anyway I implemented a system of tags for grouping similar experiments. It's less polished and sophisticated than this, but it was quick to implement and feels suitably lightweight.

I'm realizing now that the SQLite database was a misstep, mainly for adding notes and metadata. So I'm planning to just use the filesystem instead so that one's raw experiment runs can be versioned as plaintext files (at the moment, just the static site is versioned)

But for now I need to get around to actually doing the experiments :(

Is this kinda what you want? https://peps.python.org/pep-0750/

(similar to template literals in JS)

You can also do something similar using f-strings, at the risk of content injection attacks.

That’s also because they were not called SPAs for the first 15 years of the web.

The very first technology for building “SPAs” was Java Applets. Corel released a web-based office suite already in 1997, and it was practically an applet for each app.

This was replaced by Flash because Macromedia did an incredible job of getting Flash Player preinstalled on every desktop computer. If you wanted to deliver a rich and seamless app-like web experience in 1999-2004, you used Flash. (It was mostly very primitive as a dev environment, but did a great job at vector motion graphics and video.)

The original progenitors of present-day SPAs are Microsoft Outlook for Web and Google Maps. Outlook invented the ubiquitous XmlHttpRequest object, and Google Maps became so popular that it coined “AJAX.”

Following these examples, people started building DOM-based JavaScript apps that loaded data asynchronously and built up views entirely in code. And that’s when they became modern SPAs.

(There was also Silverlight and some other technologies that vied for the rich web app crown, but JS/DOM carried the day especially when iPhone happened and wouldn’t support anything else.)

I'm increasingly getting to this point as well. I think modern webtech is incredible in many ways, and if properly used could be pretty great but overall and for the most part we are pretty terrible at it. I've started to dread using SPAs because I know it's going to be sluggish and load megabytes of junk, and will still require frequent page reloads when clicking stuff Even though ostensibly it should not.

There's an exceptional beauty in a simple and lightweight website that is just a load and done. I've started doing more with Phoenix and Alpine for the little bits of client-side functionality required, and have been very pleased with it. The most interesting part though, is that users have also been very pleased. They can't explain why in technical terms, but they know it feels better.