That's a quite fair point, but as a counter point in most business cases you do want specific views (even specific searches and user applied filters) to be addressable - it's one reason why I think the history/location API is such a necessity for SPAs. And if you do have an address like example.com/#widget/view?hideWhitespace=false then you can bind your link href to that address and then, if the link is engaged without modification, do your fancy SPA stuff.

I also think in the modern world that as long as your assets are all properly versioned with good cache control headers using actually web requests for navigation instead of a self-contained SPA makes a lot less sense. Once upon a time an SPA was a solution to shifty internet, limited bandwidth and rich web experiences - those arguments have become a lot less valid in the modern world.

(this is a topic extremely near and dear to my heart as a (eh-sorta) full stack developer that needs to suffer through many poorly built applications as a user)

couterpoint: users don't care if your page is SPA. They care about opening new tabs.

Exactly. It don’t care if it takes more work for you as a developer to make everything a pageable URL. Just make it work the way I expect it to work.

... and developers don't care if users like new tabs, they write SPAs.

After spending a day trying out a new framework my junior dev asked me: "why don't we do it the old way? We would have finished the first feature already. We can do everything the framework does already with our old tools"

So I reverted my changes and worked on features instead of stack

Quite a good thing for a junior dev. Not being swept away by hype and being focussed on the thing one actually should accomplish. I don't know that person, but this smells like there is potential.

That junior developer’s name? Albert Einstein.

Give that junior a promotion.

I'm not defending it! I hate it too!

I was just responding to it being a criticism of 'designers', maybe I misread that, but my initial reaction was as above, that it's not completely trivial to allow, or like it necessarily comes for free and has been 'turned off' by design.

When users want to open things in new tabs (hopefully having a state representing URL), then there might be something about the website, that does not actually want to be a single page web application. Sometimes users simply want to "open things for later viewing" or bookmark things. Basic functionality of any modern web browser.

There are plenty of SPAs that can open things in new tabs just fine and there are plenty of MPAs that can't.

I made almost the exact same comment as GP elsewhere.

One thing that I noticed is that more than half the time "open in new tab" is broken, I can click the link, copy the URL, open a new tab, paste the url and get what I wanted. It's so maddening.

Often the problem if you develop something as a SPA then your framework probably has different state management solutions built in that you will develop with, without any way to easily tie that state to a particular url or to pass a bunch of state to a new window. Thus opening new window puts you in default state of the SPA.

This is of course maddening if the site should not be a SPA but was developed that way because when you are running a company and need to build things quickly it is easier if you just have one toolbox labelled SPA-building tools and pull that out and get going.

> It's not really just about (UI/UX) design, to be fair, being able to open in a new tab requires that it's a directly navigable 'page' by URL to begin with.

I'd argue that each individual view in your app should have a routable URL, otherwise sharing links to anything is basically impossible, as is bookmarking certain pages, or even reloading them.

> With SPAs, that's often not true for entire 'pages', never mind modals and views you might not be expected to want in a new tab but do.

Some claim that modals are bad design and I wholeheartedly agree, though for a variety of reasons they still keep showing up across numerous systems. I guess a compromise could be giving the modal open state its own URL so the app would know what to do if the page is refreshed (the modal would still be open), but somehow that doesn't get much attention either.

An especially clever option (for niche cases) would be being able to open a modal in a tab/window of its own, without the surrounding UI, when opened directly through the URL/new tab/new window, but show it inline in the app during normal navigation. Then again, many dislike pop-ups either because that's not really the direction in which web development went, though I can see why in certain sites they could be useful (e.g. CRUD apps with lots of boring tables and element selection). Oh well.