For writes you’re absolutely right, the best you can do is optimistic UI and spinners, but for reads you can get almost the same thing with an SPA by prefetching data. Usually, it takes one entire client.prefetchQuery inside a requestIdleCallback.

I am fully aware of the time cost of maintaining an SPA. I’ve been writing JS since we called interactive UI made without using flash or java “DHTML”, the number one way of fetching data on the client was jsonp and there was this exciting new function on the horizon called document.querySelector. If all you know is backend programming then yes it looks very scary but if you’re familiar with the environment and pin your dependencies frontend code is just as simple to maintain as backend code.

There is absolutely extra cost in developing the app, but there is also cost from lost productivity waiting for a loading spinner. There is a reason things like GraphQL/Relay exist and it is not for developer velocity. It is very easy to take loading times for granted if you live in the US or Europe where the servers are close.

If you watch this video of me using livebeats, every one of these page transitions would benefit from prefetching page contents. This is pretty much the best case scenario for an Australian connection with gigabit fibre with good peering. Compare this to this recording of me using Tidal, an SPA and you can see the transitions are almost instant, despite the server also having ~300ms of latency, as demostrated by when I open a playlist that is yet to be cached.

Somewhat ironically, the same sort of speed can be achieved with phoenix, but only if you use “dead” views, because link rel="prefetch" works just fine for full page transitions

Been looking at this thread and thinking…

I think the problem with fetch (and the iframe) in the case of LiveView is that it probably doesn’t help make the live navigation (over the persistent WebSocket connection) any faster, and brings questions about behavior.

JS fetch would probably cause only a “disconnected mount” of the prefetched page/LiveView, while the iframe would trigger both disconnected and connected mounts with a full LiveView process on the server which can’t really be reused when the actual navigation happens.

I think the approach that astro does is the cleanest and mostly leveraging browser standards:

1. It prefers using speculation rules, if available
2. It falls back to rel=prefetch, if available
3. finally, resorts to using fetch()

They also keep track of already prefetched URLs in a set and bail early.

Prefetching can be configured to be global on the project, opt-in/out per link, etc. Very good ergonomics!