Who’s Afraid of a Hard Page Load?
May 23, 2025
The friction involved with a hard page load doesn’t exist because web developers are too lazy to do performance work—it reflects a real, physical limitation in the system that is beyond the ability of one developer, and possibly humanity, to overcome. SPAs not only fail to remove the need for the network call, they diminish the user’s ability to manage when that network call is made, and handle failure cases.
When the iPhone came out people lost their minds. Well in lots of ways. Obviously it was a paradigm shifting new platform and hardware device.
But when apps came to the platform, where previously web technology had been the way to develop for this marvel, then criticism of web apps versus native apps emerged. And a significant aspect of the superiority of native apps over web apps was perceived performance. I mean when the hundreds of MBs or GBs of code for your app are right there on the device, as opposed to needing to be downloaded to be used, there’s an advantage right there.
The response of the Web development profession to this was the single page app architecture. First download the app scaffolding, then load in the specific parts of the app required by the user. Transitioning between different stated can be all ‘buttery smooth’ like all those native app animations we envied.
Here Alexander Petros argues against that, that “The web has seams, let them show”
Developers are naturally inclined to make their applications feel more responsive, and when they test their SPA, it feels like a more natural experience than a clunky old web page. But this instinct is usually incorrect, because most websites need to hit the network in response to user actions.
The web is a medium-it is not paper as it took the first decade of its existence and more to work out, but it’s not an operating system of app platform either, though it rhymes with both things.
