Dear all,
Good examples of Progressive Web Apps seem to very often be single-page-applications. I don’t like SPAs, which seem to me to attempt to replace functionality that the browser can and should do much better, such as memory management, back-and-forward navigation, and restoring scroll position.
However, browsers consistently deliver poorly on the actual experience of navigating between pages, when compared to native apps. In native, typically a view is rendered all at once, and often transitions into view with a visual effect. In web, we are limited to starting with a blank screen when the first byte of the response is received. Other issues include the lack of a BFCache in some browsers which necessitates the re-rendering of the previous page when returning to it with the back button.
I propose to start tackling this with a simple mechanism that will delay the unload of a defunct page until the new page is rendered. At it’s simplest this could take the form of a boolean opt-in:
<a href='page2.html' prerender>
This would leave the decision about what counts as ‘rendered’ to the browser. Alternatively, handing more control to the developer, you could partner this with a JavaScript API to notify the browser of when a view is ready to be shown:
document.visuallyComplete();
The browser would probably apply a timeout to this, say 2 seconds. WDYT?
Also relevant: Web Navigation Transitions proposal by Chris Lord from Mozilla.
Please contrast with:
<link rel="prerender" href="http://example.com/nextpage.html" />
Why can’t I simply set the above when I suspect a user is likely to navigate to a particular URL?
1 Like
That’s a different use case. If I have a news homepage with 100 stories on it, I can’t pre-render all of them. And neither will native apps. But they will fully compose the view before sliding it in. That’s what I want to do on the web.
Also relevant: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/EFw5sJgcqjU
I agree that in many cases the “single page app” model is not necessary other than UX reasons, in order to ensure smooth transitions between pages. Providing a way to provide that with the multi page “traditional” model makes a lot of sense.
However, I’m not sure that avoiding the white screen by simply waiting until first paint (or other time) of the new page would provide an improved user experience over what they have today.
Perhaps people here know a bit more on the history of the various nav transitions efforts and why they weren’t followed up on.
Asking around, it seems like the previous solutions were held off as “too magical” and the premise that primitives such as Houdini will enable the same.
@iank - is the use case for “navigation transitions” covered by any of the Houdini related specs?
Discussed today with @KenjiBaheux, and he suggested something like this (I take no responsibility for how disturbingly horrible this is!):
<script>
function onPrerender(el) {
location.href = el.href;
}
document.addEventListener('click', function(e) {
if (!e.target.matches('a.prerender')) return;
e.preventDefault();
var linkel = document.createElement('link');
linkel.rel = 'prerender';
linkel.href = el.href;
linkel.onload = onPrerender;
document.head.appendChild(linkel);
});
</script>
<a href='article-345023.html' class='prerender'>Go to an article, one of many</a>
However, since this isn’t working for me, I suspect there is no onload
event on a link rel=prerender. When I get a minute I’ll look into whether the prerendered document can postmessage the opener.
Also relevant, Google is aiming to remove prerendering from Chrome in favour of a lighter No state prefetch
Some of the arguments presented here may also be relevant to the idea of rendering a view before transitioning to it.