Anyone that builds a SPA and breaks opening in new tab or history caching and back/forward nav isn't a good frontend developer (or lacks experience, which is something that's fixable!). These have been solved problems for a long time.
I was kindof chief architect for a project where I worked. I decided on (and got my team on board with the idea of) making it an SPA. Open-in-new-tab worked perfectly.
(One really nice thing about it was that we just made the backend a RESTful API that would be usable by both the JS front-end and any automated processes that needed to communicate with it. We developed a two-pronged permissions system that supported human-using-browser-logs-in-on-login-page-and-gets-cookie-with-session-id authentication and shared-secret-hashing-strategy authentication. We had role-based permissions on all the endpoints. And most of the API endpoints were used by both the JS front-end and other clients. Pretty nice.)
I quit that job and went somewhere else. And then 5 years later I reapplied and came back to basically the exact same position in charge of the same application. And when I came back, open-in-new-tab was broken. A couple of years later, it's not fixed yet, but Imma start pushing harder for getting it fixed.
What some folks are missing is that SPAs are great for web applications & unsuitable for web pages. There is more nuance than “SPA bad”.
Then dealing with a lot of dynamic content, piping thru a virtual DOM DSL is 100× nicer for a developer than having to manually manipulate the DOM or hand write XML where it’s easy to forget all the closing tags (XML is better as a interchange format IMO & amazing when you need extensibility… also JSX just makes it worse). That developer experience (DX) often can lead to faster iteration & less bugs even with a cost to the user experience (UX). But it’s not always a negative impact to the UX--SPAs can be used to keep things like a video or music player on while still browser & using the URL bar as a state reference to easy send links to others or remember your own state.
It’s equally silly that a landing page whose primary purpose is to inform users of content takes 40s to load & shows “This applications requires JavaScript” to the TUI browser users & web crawlers/search indexers that don’t have the scale of Google to be executing JavaScript in headless browser just to see what a site has to say.
The trick is knowing how & when to draw these lines as there’s even a spectrum within the two extremes for progressive enhancement. React isn’t the solution to everything. Neither is static sites. Nor HTMX. Nor LiveView. Nor Next/Nuxt/Náxt/Nüxt/Nœxt/Nอxt.
It's fascinating how some SPAs come about. Often consultancies who win some bid to implement X features. Since "good user experience" is hard to quantify/specify, it ends up being a horrible end result.
Zalaris is one such that I'm in complete awe of. Set up user flows that are expected to take 30 minutes to complete. Yet, don't keep track of that state/progress withing your own SPA. Click the wrong tab within that SPA, and state is reset.
Building "applications" out of HTML documents -- a single one or otherwise -- is the sort of thing that belongs in one of those "stop doing X" memes, unironically.
HTMX is great and is the only frontend development tool I don't absolutely loathe. It enables lightweight SPA development, and provides a very simple and efficient mechanism for doing HTML over the wire.