4 ms·

> 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 oft

> 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.

PaulHoule 3y ago
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 3y ago
  Sure. You maintain the entire application state in session scope or some sort of internal state. It was possible, but it was hell.
  - PaulHoule 3y ago
    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.
wwweston 3y ago
> "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 3y ago
  > 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!
pier25 3y ago
> 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.
deleted 3y ago
[deleted]
seabass-labrax 3y ago
> 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!

PaulHoule 3y ago

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 3y ago
Sure. You maintain the entire application state in session scope or some sort of internal state. It was possible, but it was hell.
- PaulHoule 3y ago
  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.

wwweston 3y ago

> "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 3y ago
> 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!

pier25 3y ago

> 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.

deleted 3y ago

[deleted]

seabass-labrax 3y ago

> 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!