Who's Afraid of a Hard Page Load?
55 points by blaix
55 points by blaix
there’s a decent chance that the browser can save me: the back button will usually load the cached version of the page I was just on.
Is it me, or is this getting worse and worse on mobile? It seems like even just switching tabs usually triggers a complete reload, if the tab is more than a few minutes “old”.
On modern browsers, the mechanism behind this behavior is quite complicated: https://developer.chrome.com/blog/memory-and-energy-saver-mode
This is designed to allow users to keep hundreds of open tabs on devices with little memory.
I think defaulting to server side rendered pages for web apps are the best default.
I’d also encourage people to not use frontend flavoured web frameworks that let you do “server components”, “islands”, “hydration” etc etc. It’s complete over engineering, just make a normal server side rendered website first. You probably need a lot less fine grained reactivity than you think.
Every day I ride the New York City Subway. For my carrier, most of the stops have cell service, and most of the tunnels between stops do not.
It’s worth pointing out that New Yorkers should be angry about this. It’s a policy choice to inadequately wire the subway, and it doesn’t have to be this way.
the page fails to load, and now I’m looking at a blank screen.
This particular behaviour also seems to be a policy choice of browsers, and it doesn’t have to be this way.
If you got a simple HTML page that was not a result of a form submit, and the browser decided to refresh, it should: a) leave the current, perfectly readable version of the page alone, and b) if the refresh is not successful due to network issue, leave the page alone. Maybe indicate this condition somehow, but current behaviour is almost always completely unnecessary.
It’s mostly a historic choice I suspect. Arguably it also makes it very clear what happened as opposed to some indicator like you propose.
Anyway, the author’s point isn’t that this behavior by browsers on traditional pages is perfect. But that it is at least much better and recoverable compared to how SPAs typically handle this sort of thing.
I never went to New York, but there’s the same issue in many subway lines in Paris, even in some of the large recent ones. I’m sure it’s much easier to setup cellular antennas at a stop than in a tunnel. And in fact I’m not even sure that we will have a decent cell service in most tunnels some day, the transportation network is complex and critical, some sections are 125 years old… it’s already a real challenge to just make it work!
It took a very long time to get there, but it’s doable of truly desired. Berlin subway has decent connectivity and the providers paid for the underground base stations.
Amen! I was blown away when I went to South Korea and nearly everyone I could see on the packed subway was streaming HD video to their phones. That was 2014.
I find that a lot of web developers don’t appreciate how much work the browser does. This article touches on the back-forward cache which is probably 100x more complicated than you think it would be at first glance, but I also see this with much simpler components such as buttons and links. A link is just something that when you click on it changes the URL right? It is so easy to forget that browsers also have controls to open links in new tabs, container tabs, new windows, private windows, bookmark the target of the link, download the target of the link, show the link target on hover, maybe even preload the link target when you get close to it, extensions may let you search for the target of the link on a website archive or even let you send the target of a link to a different device that the browser syncs with! I’ve probably listed less than half of the native functionality (I haven’t even talked about keyboard controls and accessibility), your <span onclick> pales in comparison to a native <a href> and you spent more time, more effort and more resources to do it!
I think a good strategy for making a really nice and usable web app is to use as much native functionality as possible. It has more functionality than you could ever imagine, basically for fee, and it is getting better over time.
1000% this. You are throwing so much away when you try to get clever and reinvent browser features, and I suspect that the reason for doing so is almost always misguided or misunderstood.
I use Ctrl+click a lot to open new tabs. Naive implementations often break this because they’re not checking the MouseEvent for the Ctrl modifier, and it’s really frustrating because it’s like they went out of their way to break it! Just use a link!
To be fair this is not the fault of the SPA architecture itself. React does not dictate that you have to use a span with an onclick instead of a link. But I think it is a symptom of the same framework-happy culture that undervalues the web as a platform. Use the platform!
The entire concept of SPAs and how they’re often implemented often makes me rather cynical about the claims why they are being developed. A lot of the claimed benefits are often not really realized, but what they nicely do is offload server side rendering to the client.
Yes, yes, I know that these days many frameworks support server side rendering for a lot of the content that is loaded in. But that wasn’t always the case, certainly not when SPA centered frameworks first reared their heads.
I don’t mind dynamic content and elements. But as soon as it does all the things traditionally associated with a page change (like changing the URL and showing completely different content) then please give me a hard page load. Because, at that time we are long past a single page to begin with…
What claims are you referring to, though?
Many people may have opted for SPAs for snappier navigation a decade ago, but I doubt many are making that argument today. It’s become a low-hanging fruit for SPA critics now that improvements in browsers have narrowed the gap. At this point delegating navigation to a JS library is a necessary evil more than anything; without it, we’d have to rebuild the JS environment on every page load, losing state.
If your only justification for building a SPA is fast navigation, then sure, you probably should re-evaluate your options. But I think there are legitimate reasons for going with a SPA if you’re dealing with complex reactive interfaces.
At this point delegating navigation to a JS library is a necessary evil more than anything; without it, we’d have to rebuild the JS environment on every page load, losing state.
That’s the thing though, so very often I see SPAs where there really isn’t much “state” to hold on to begin with. To be clear, I think there are use cases for SPA frameworks and the methods they offer. I also think that SPAs are often used as part of the old mantra “if all you have is a hammer”.
I realize this is a bit of a hot take, but most websites where SPA principles are applied to don’t need it and are worse in many ways because of it.
Also, there are more ways to maintain state as long as we are talking simply data. There is of course local storage, but also maintaining state server side. Which, depending on the use case, is not only valid but also provides a more stable experience for the user.
I realize this is a bit of a hot take, but most websites where SPA principles are applied to don’t need it and are worse in many ways because of it.
Every single dashboard-behind-a-login I’ve worked on professionally has benefited from being an SPA, especially when there’s already a REST API. These SSR frameworks like nextjs are almost entirely overhead when compared to sending some static files to nginx. Seriously, the complexity of having a “back-end for your front-end” is an abject disaster. And don’t get me started on react server components which as far as I can tell was created purely as a pipeline to get people paying for vercel.
Yes, I’ve also seen the countless blogs and throwaway “apps” that inexplicably ship megabytes of JS when all they hold is static content. It’s just that I don’t think it makes much sense to make categorical statements about the promises of SPAs by looking at misguided uses of them. I’m not pinning this on you, but I hear people say this kind of stuff all the time and it’s getting old.
I also think that SPAs are often used as part of the old mantra “if all you have is a hammer”.
I think this hits the nail on the head. Many developers are very comfortable with their SPA ecosystem and don’t want to spend effort figuring out alternatives. To a degree, I can emphatize with that, and I think the fact that people keep building static pages with these frameworks says something about the developer experience they offer.
I’m cautiously optimistic about developments such as React Server Components or the Islands architecture that could reduce the harmful UX-hindering aspects of SPA/MPAs while retaining the familiar DX. Astro lets you use components from any framework and everything is rendered on the server by default. I think it’s the framework a lot of people don’t know they want.
It’s just that I don’t think it makes much sense to make categorical statements about the promises of SPAs by looking at misguided uses of them.
Good thing I am not doing that then ;) I am not deriving promises from the use of them, I am talking about how I remember a lot of these frameworks were introduced to the market. Back when React and AngularJS were the new shiny. As far as I recall, a lot of the use cases for them specifically centered around SPA and SPA concepts.
and I think the fact that people keep building static pages with these frameworks says something about the developer experience they offer.
Possibly, at the same time, if you never learned to do otherwise for many people it doesn’t matter that there are alternatives out there. They are going to stick with what they know, even if it isn’t necessarily easier. KISS can only be applied if you know the simple.
I’d argue that even “complex reactive interfaces” aren’t really a satisfactory justification most of the time, these days. The time you need an SPA is when your application basically, fundamentally doesn’t fit with a “page” model. The map example in the article is a good example. Drawing applications would be another. But more stuff fits into the “page” model than most front-end developers seem to think.
Is it really more expensive to generate HTML on the server side than it is to generate JSON?
(that’s an honest question, I really don’t know, but at first glance it does not seem fundamentally different)
Comparatively speaking it is, since you need to generate the complete structure as opposed to just sending a json payload to the front-end. Basically you are saving some compute on the server side as well as bandwith. To be clear, this only starts to matter at scale. Which is also where part of my theory comes from. As the initial push for SPAs largely came from behemoths like Google, Facebook, etc.
At the time a lot of devices (specifically smartphones) were also not as high spec as today. A lot of SPAs didn’t really improve all that much for the user anyway. Which further added credence to the idea that it isn’t about the user experience.
But, the notion has persisted to the point where I feel like there is an entire generation of developers who only know how to develop in a SPA context. Which leads to a lot of smaller websites that would (in my opinion) be better served by server side rendered content to be SPAs.
Also with something like htmx where you don’t send a full HTML document but only a partial one in most cases, the difference from JSON is negligible.
I have once developed a search page that used a lot of small static JSON files to make Nginx+FS act as a key-value API (the full request was hashed in the client)…