The beauty is that you can have it request the JavaScript after the HTML, so those kilos of JS don't slow down first render and by the time a user clicks something you're probably rehydrated and ready to request subsequent pages without a full refresh. On the offchance you aren't rehydrated by the time of a click you just fall back to the normal behavior of an anchor link. All the delivery/render speed of static HTML with the subsequent page load times of an SPA. I could see not liking this approach if you're trying to minimize bits downloaded, but if you're concerned about user experience I would idealise using this pattern on all internal links (pretty much -- there are weird exceptions like embedded content that refuses to run after initial render for security reasons). This approach is more complicated, but also more performant due to less overall DOM manipulation.

Step 1: client requests page.

Step 2: static HTML is delivered.

Step 3: static HTML begins rendering on client.

Step 4: client requests JavaScript attached to bottom of HTML document.

Step 5: JavaScript is delivered.

Step 6: JavaScript begins execution.

Step 7: JavaScript goes through the document replacing normal anchor links with elements that have click events which request only the content, and not the template, for subsequent pages[0].

Step 8: user clicks a "link."

Step 9: client requests content.

Step 10: content gets delivered.

Step 11: client updates part of the page and the URL bar, but doesn't cause a whole page refresh.

[0]Exception: you can give yourself hooks for a template change if you want, and even a significantly different layout on the same site will often have some common factors like footers and background.