[com2kid]

> The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check.

MPAs break back buttons all the damn time, I'd say more often than SPAs do.

Remember the bad old days when websites would have giant text "DO NOT USE YOUR BROWSER BACK BUTTON"? That is because the server had lots of session state on it, and hitting the browser back button would make the browser and server be out of sync.

Or the old online purchase flows where going back to change the order details would completely break the world and you'd have to re-enter all your shipping info. SPAs solve that problem very well.

Let's think about it a different way.

If you are making a phone app, would you EVER design it so that the app downloads UI screens on demand as the user explores the app? That'd be insane.

[wwweston]

> "DO NOT USE YOUR BROWSER BACK BUTTON"?

Yeah, state mutation triggered by GET requests is going to make for a bad time, SPA or MPA. Fortunately enough of the web application world picked up enough of the concepts behind REST (which is at the heart of all web interaction, not just APIs) by the mid/late 00s that this already-rare problem became vanishingly rare well before SPAs became cancerous.

> going back to change the order details would completely break the world and you'd have to re-enter all your shipping info. SPAs solve that problem very well.

The problem is entirely orthogonal to SPA vs MPA.

> If you are making a phone app, would you EVER design it so that the app downloads UI screens on demand as the user explores the app?

It's not only EVER done, it's regularly done. Perhaps you should interrogate some of the reasons why.

But more to the point, if it's bad, SPAs seem to frequently manage to bring the worst of both worlds, a giant payload of application shell and THEN also screen-specific application/UI/data payload, all for reasons like developer's unfortunately common inability to understand that both JSON and HTML are perfectly serviceable data exchange formats (let alone that the latter sometimes has advantages).

[com2kid]

> It's not only EVER done, it's regularly done. Perhaps you should interrogate some of the reasons why.

Content in the app is reloaded, sure, but the actual layout and business logic? Code that generally changes almost never, regenerated on every page load?

I know of technologies that are basically web wrappers that allow for doing that to bypass app store review processes, but I'd be pissed if an alarm clock app decided to reload its layout from a server every time I loaded it up!

The SPA model of "here is an HTML skeleton, fill in the content spaces with stuff fetched from an API" makes a ton more sense.

The application model, that has been in use for even longer, of "here is an application, fetch whatever data you need from whatever sources you need" is, well, a fair bit simpler.

Everyone is stuck with this web mindset for dealing with applications and I get the feeling that a lot of developers now days have never written an actual phone or desktop application.

> But more to the point, if it's bad, SPAs seem to frequently manage to bring the worst of both worlds, a giant payload of application shell and THEN also screen-specific info, all for reasons like developer's unfortunately common inability to understand that both JSON and HTML are perfectly serviceable data exchange formats (let alone that the latter sometimes has advantages).

I've seen plenty of MPAs that consist of multiple large giant mini-apps duct taped together.

Shitty code is shitty code!

[heartbreak]

> here is an application (your browser), fetch whatever data you need (html) from whatever sources you need (my web server)

Parentheticals added.

[ebiester]

It wasn't GET mutation... it was POSTs with multi-page forms that was the problem. It was such a pain to subdivide a form and create server and session state and intuit the return state. And what happens if you needed a modal with dynamic data? Did you pop open a new window and create a javascript call for the result? There was no great progressive answer to them.

Oh, and then request scope wasn't good enough because you needed to do a post-redirect-get? I will say that I do not think MPAs for web applications were the good old days.

[KyeRussell]

Yeah. As someone that’s quite bearish on JS altogether, and as someone that’s worked on a few old-school multi-step forms recently, we can’t pretend that this was and still is anything other than a code and UX disaster. And…I’m not an idiot, I understand different HTTP request types and how browsers handle going back through history. I know that there’s not something obvious I’m missing. I’ve put the work in. The reality is that non-JS web technologies aren’t very good at some things that are quite common and that many people expect in anything more than a brochure site.

I’m just so miffed that it can end up necessitating roping in so much BS. Mind you, not necessarily in this example. Things like HTMX excite me. And, on the other side, things like Next.js and Remix that IMO are a breath of fresh air, even if they might not ultimately be heading in the right direction (I genuinely have no idea).

[PaulHoule]

It is totally possible to make MPAs where reloads are never a problem.

As for phone apps these are undeniably a step backwards from desktop apps, web apps and every other kind of app. On the web you can deploy 100 times a day, waiting for the app store to approve changes to your app is like building a nuclear reactor in comparison.

All the time you get harassed in a physical store or a web site to "download our mobile app" and you know there ought to be a steaming pile of poop emoji because the mobile app almost always sucks.

One of the great answers to the app store problem is to move functionality away from the front end into the back, for instance people were looking to do this with chat bots and super apps back in 2017 and now that chatbots are the rage again people will see them as a way to get mobile apps back on internet time.

[ebiester]

Sure. You maintain the entire application state in session scope or some sort of internal state. It was possible, but it was hell.

[PaulHoule]

Or the other way around, you keep as much as you can on the client but use nonces in critical requests to prevent (accidental) replays.

[seabass-labrax]

> Remember the bad old days when websites would have giant text "DO NOT USE YOUR BROWSER BACK BUTTON"?

It was even worse when the page didn't warn you, but would lose state all the same!

[pier25]

> If you are making a phone app, would you EVER design it so that the app downloads UI screens on demand as the user explores the app? That'd be insane.

Good luck forcing users to download 50MB before they can use your web app.

The web and mobile/desktop apps are two totally different paradigms with different constraints.