
Playing tunes with Jessica.
Playing tunes with Jessica.
Session in the sun. 🎶 ☀️
Flamenco y gato.
Getting stuck in!
I endorse this statement.
Checked in at Asador Carlos V. Lunch on the square — with Jessica
The Cáceres sessions begin.
Checked in at Taberna El Rincón. Croquetas y vino — with Jessica
Checked in at La Minerva. Pulpo! — with Jessica
Checked in at almagesto. Lunch on the square—mogote de cerdo Ibérico — with Jessica
I got a nice email from someone regarding my recent posts about performance on The Session. They said:
I hope this message finds you well. First and foremost, I want to express how impressed I am with the overall performance of https://thesession.org/. It’s a fantastic resource for music enthusiasts like me.
How nice! I responded, thanking them for the kind words.
They sent a follow-up clarification:
Awesome, anyway there was an issue in my message.
The line ‘It’s a fantastic resource for music enthusiasts like me.’ added by chatGPT and I didn’t notice.
I imagine this is what it feels like when you’re on a phone call with someone and towards the end of the call you hear a distinct flushing sound.
I wrote back and told them about Simon’s rule:
I will not publish anything that takes someone else longer to read than it took me to write.
That just feels so rude!
I think that’s a good rule.
Well, I wasn’t expecting…
Checked in at Mercado de San Fernando. Vermut! — with Jessica
It looks like it will be a great tool for prototyping. A tool to help developers that don’t have experience with CSS and layout to have a starting point. As someone who spent some time building smoke and mirrors prototypes for UX research, I welcome tools like this.
What concerns me is the assertion that this is production-grade code when it simply is not.
This is quite mesmerising—click on an image that takes your fancy; see it surrounded by related images; repeat.
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
Checked in at Dover Castle. Tuesday night session — with Jessica
The slides and transcript from a great talk by Maggie Appleton, including this perfect description of the vibes we get from large language models:
It feels like they’re either geniuses playing dumb or dumb machines playing genius, but we don’t know which.
Enjoyed some lovely tunes tonight!
Checked in at The Ancient Mariner. First Thursday of the month session — with Jessica