It's a fun one liner, but what is the use case?
When I want to replace some element using JS as the user clicks a link, it is progressive enhancement.
Usually links enable history navigation. If you do stuff like this, you need to code it in a way that uses the history API to fix it for users with JS enabled (majority of users).
If you don't want history navigation and URLs, why do you use links?
This breaks history navigation and bfcache for no good reason, or am I missing something? bfcache already provides SPA-like speed, or even better.
No need to avoid regular links if you e.g. link from a list to a detail page.
Also:
> No preventDefaults. No hidden layers. Real DOM, real interactions. No VDOM, no click listeners. No AJAX, no fetch. No reinventing browsers.
So many words saying nothing, just to cater to some sentiment. fetch is part of browsers by the way.
If I need to replace an element as the user clicks a link, I can code it myself (without using this abstraction layer, however thin it is). I also don't need an iframe for doing this. And preventDefault is aptly named and a good reminder for what progressive enhancement should do. If it's not meant to be a link, don't use a link.
And if you want to react to clicks, you know, use click listeners (event handlers). Where's the problem?
It is understandable to developers and uses native browser functionality as intended. As opposed to this hack, which I'd find pretty glaring, bug-prone and hard to understand, would I have to debug an issue on some page that uses this snippet.
To me this seems like useless indirection and technical debt.
If you really need low-code AJAX "links" (who says you need that, if you don't want an SPA?), code yourself some understandable JS that is properly tailored to your site and respects history navigation, or use a library that is a good fit for your concrete use case.
As a joke, I like it though…