Replying to
I love to see unplanned harmonic resonances like this!
I love to see unplanned harmonic resonances like this!
From the reader of your blog’s perspective, there’s also Simon’s rule to consider:
https://adactio.com/journal/20457
I will not publish anything that takes someone else longer to read than it took me to write.
Ooooh, cool! Colour me very intrigued indeed—really looking forward to seeing it!
I received this email recently:
Subject: multi-page web apps
Hi Jeremy,
lately I’ve been following you through videos and texts and I’m curious as to why you advocate the use of multi-page web apps and not single-page ones.
Perhaps you can refer me to some sources where your position and reasoning is evident?
Here’s the response I sent…
Hi,
You can find a lot of my reasoning laid out in this (short and free) online book I wrote called Resilient Web Design:
https://resilientwebdesign.com/
The short answer to your question is this: user experience.
The slightly longer answer…
For most use cases, a website (or multi-page app if you prefer) is going to provide the most robust experience for the most number of users. That’s because a user’s web browser takes care of most of the heavy lifting.
Navigating from one page to another? That’s taken care of with links.
Gathering information from a user to process on a server? That’s taken care of with forms.
This frees me up to concentrate on the content and the design without having to reinvent the wheels of links and form fields.
These (let’s call them) multi-page apps are stateless, and for most use cases that’s absolutely fine.
There are some cases where you’d want a state to persist across pages. Let’s say you’re playing a song, or a podcast episode. Ideally you’d want that player to continue seamlessly playing even as the user navigates around the site. In that situation, a single-page app would be a suitable architecture.
But that architecture comes at a cost. Now you’ve got stop the browser doing what it would normally do with links and forms. It’s up to you to recreate that functionality. And you can’t do it with HTML, a robust fault-tolerant declarative language. You need to reimplement all that functionality in JavaScript, a less tolerant, more brittle language.
Then you’ve got to ship all that code to the user before they can use your site. It might be JavaScript code you’ve written yourself or it might be a third-party library designed for building single-page apps. Either way, the user pays a download tax (and a parsing tax, and an execution tax). Whereas with links and forms, all of that functionality is pre-bundled into the user’s web browser.
So that’s my reasoning. At least nine times out of ten, a multi-page approach is leaner, more robust, and simpler.
Like I said, there are times when a single-page approach makes sense—it all comes down to whether state needs to be constantly preserved. But these use cases are the exceptions, not the rule.
That’s why I find the framing of your question a little concerning. It should be inverted. The default approach should be to assume a multi-page approach (which is the way the web works by default). Deciding to take a JavaScript-driven single-page approach should be the exception.
It’s kind of like when people ask, “Why don’t you have children?” Surely the decision to have a child should require deliberation and commitment, rather than the other way around.
When it comes to front-end development, I’m worried that we’ve reached a state where the more complex over-engineered approach is viewed as the default.
I may be committing a fundamental attribution error here, but I think that we’ve reached this point not because of any consideration for users, but rather because of how it makes us developers feel. Perhaps building an old-fashioned website that uses HTML for navigations feels too easy, like it’s beneath us. But building an “app” that requires JavaScript just to render text on a screen feels like real programming.
I hope I’m wrong. I hope that other developers will start to consider user experience first and foremost when making architectural decisions.
Anyway. That’s my answer. User experience.
Cheers,
Jeremy
Yeah, but it looks like we’re serenading our pints!
It’s actually one of the oldest web components in the wild—Github’s been using it for a decade:
https://github.com/github/relative-time-element
(But I wanted something I could drop into an existing site without changing markup.)
Did you take any pictures of Ella‽
Thanks for the pointer!
I was able to update my “indy map” in no time:
No, I’ll be playing traditional Irish music all next week: https://www.belfasttraditionalmusic.com/
How long are you going to be in Belfast? I’m heading there tomorrow.
I use https://brid.gy/ to get sent webmentions whenever there’s a response to a syndicated post.
I wrote up some of my bits’n’bobs a while back here:
Yeah, under the hood it’s a horrific concoction of PHP and MySQL.
For posting notes, there’s a form that appears just for me (if I’m logged in) in that section of the site:
Something like this, perhaps?
- Be skeptical of PR hype
- Question the training data
- Evaluate the model
- Consider downstream harms
There’s a chapter about it in the Francis Spufford book, Backroom Boys: The Secret Return of the British Boffin.
I love that this twenty-year old blog post is still available at its original URL …and that I can read the comments from @anildash@me.dm, @daveshea@tilde.zone, and @beep@follow.ethanmarcotte.com.
That was Dunstan Orchard!
Taken together, these flaws make LLMs look less like an information technology and more like a modern mechanisation of the psychic hotline.
Delegating your decision-making, ranking, assessment, strategising, analysis, or any other form of reasoning to a chatbot becomes the functional equivalent to phoning a psychic for advice.
Imagine Google or a major tech company trying to fix their search engine by adding a psychic hotline to their front page? That’s what they’re doing with Bard.
Circe by Madeline Miller.