While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). If implemented correctly, JavaScript navigation should seamlessly appear like normal navigation. Not supporting streamed requests is a serious drawback.

Of course browsers have actually gotten pretty good at AJAX-like loading instead of completely re-rendering the page. These systems tend to rely on heuristics though, and I don't think there's any documentation for these, but even when these fail the browser tend to be more competent than even the best JavaScript solutions.

I think there are good use-cases for SPAs (Google Maps, for example), but the majority of cases that I've seen aren't good ones, and the extra complexity involved in managing state etc. far outweighs any marginal gains in not re-instantiating JS.

> While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs).

Your JavaScript shouldn't be blocking page load anyway. Defer, defer, defer.

JS is cached in its compiled state in modern browsers. There is no download or parsing step for repeated loads.

without a unique key in the js name/path, or any server action to enable it? If so I would like to read about this particular development - can you point me to an article on how they're doing it?

Yes, Chrome uses V8 which has Isolates (also used by some FaaS platforms like Cloudflare Workers), and adds more optimizations on top like disk-based caching to share across processes. The script is keyed from a hash of its contents.

https://v8.dev/blog/code-caching-for-devs

Thanks! I guess will have to see if FF and Safari support same thing. Perhaps in another year can remove cache busting from builds.

They do, it's linked in the blog:

https://blog.mozilla.org/javascript/2017/12/12/javascript-st...

https://bugs.webkit.org/show_bug.cgi?id=192782

Also did you mean http caching? Not sure why would want to remove that. It's still important for the browser to get the latest script content before the bytecode caching happens.

How can the download step be skipped then if you are using the hash of the content as a key??

That's what HTTP caching is. Browsers use headers and heuristics.

What if there's no content to download? The client could have the same algorithm that the server could render.

For example create a melody with seed: 4564342

The client can render it and if you access it from the server the server does the rendering with the same seed.

Caches also exists, now with PWA-s offline modes would benefit from the History API.