Proper SPA frameworks have been able to do this extremely well for nearly a decade now, without any effort from the developer.

So you now need a framework to accomplish something browsers have been able to do natively for multiple decades. And we're calling that progress.

window.history is from the HTML 5 spec from 2011. It’s as native as anything else.

The API is mature but usage is not. I still see cases where companies screwed up state management on at least weekly basis so clearly the SPA-building community is still lagging behind where the server-side world was three decades ago.

Just wait til you learn about SSR

For real.

The solution to bad url routing in SPAs is distributing our work across a madcap wild ass front-end/back-end split with ill defined borders & no protocols? What's happening now is 500% more complicated.

But the magic is well packaged & available by default.

The SSR world has frameworks: but as another commenter pointed out, React stopped at being merely a library. And so it's been anarchy, deciding how to SPA, with many folks not realizing how many needs/libraries they really needed to have.

I'm hugely in favor of SPAs, but there's been a lack of well-integrated sensible approaches. The attempt to identify & only solve a narrow window of concerns has hurt our ability to imagine what apps are, left huge voids all over.

And yet hardly any SPAs manage to use it

A well done SPA is pretty much indistinguishable from server side rendering. Perhaps even better. They use real links which you can copy and middle click, but if you regular click, js hijacks the event and changes the page without a full page reload and then inserts a history event so it’s just like a normal link but slightly better.

The hate for single page apps is about bad ones. Which are unfortunate common

Except that it's not just like a normal link. It's a button dressed up as a link. A translinkingbutton, very current in this this time of age, I hop I don't offend any buttons.

What happens if you press shift? or cmd? and in which browsers / OSes? What if you use enter to open links, will it have a tabstop? What about accessibility. You're in essence re-creating the many parts of the webbrowser.

> The hate for single page apps is about bad ones. Which are unfortunate common

That's the same reason people hate php and c++

You can make great things with both..

It’s not a button. It’s an actual a tag with a href. Additionally it has an on click handler. If you open the link in any way other than clicking, it uses the href like a normal link.

Things like React Router make it trivial to create real links that additionally can change the page without a page reload if they are clicked. But you can still middle click to open in new page, still hover to see link, still navigate history normally, etc.

If and only if it hadn’t been mutilated, which happens about 99% of the time. And the whole point of this.

Sure you can make this work, but people don’t put in the extra hours of education, research, implementation, and testing

You don't really seem to understand how the History API works. They're normal anchors that have an handler attached. When the handler is executed, the transition to another page is handled client-side. If you open the link in another page, or bookmark, or deep link in any other way, the SPA loads in its entirety and shows the right content anyway. Most of the time, with lazy loading and caching, the actual number of bytes on the wire is less than serving a whole server generated page of content.

Can you name a couple? I can't think of a single example like what you describe.

Almost every google site is a SPA and work flawlessly. Spotify web works very well, even better than server side rendering as it can continue audio playback between pages.

Imo the main issue with spas is they can be very fragile and don’t handle errors because they were built lazy. And since it’s all async, the spinners keep spinning forever despite the request failing already.

> Imo the main issue with spas is they can be very fragile and don’t handle errors because they were built lazy.

I think that’s the key point: the more browser functionality you take over, the more of a resource commitment you’re making to support that extra code. If you’re Google or Spotify, you can easily afford that and in the latter case you have a strong argument for necessity because there’s no way to keep the music playing across page-loads.

The key part is making sure that you’re taking on an appropriate level of work for your team and site. A local restaurant website should probably prioritize loading quickly since most people are looking for fast answers and the owner doesn’t want to pay to maintain a heavy tool chain which requires frequent maintenance.