A single-page app is almost always worse than a multi-page app
1–10 of 152 posts
Re: A single-page app is almost always worse than a multi-page app
#2[deleted]
Re: A single-page app is almost always worse than a multi-page app
#3I want to hug Greg for this article and especially this paragraph at the end:
"Third, if you’re implementing a very complicated component then you can use React just for that component. For instance, if you’re building a chat box then there’s really no need to implement your login page in React."
Re: A single-page app is almost always worse than a multi-page app
#4I get where the author is coming from but if your frontend team is already proficient at making SPAs then going SPA from the start actually simplifies things and buys you room to maneuver. The backend team can focus _just_ on the server side and the frontend team can just request the needed APIs. Additionally you can now reuse the API you just built with other systems. If your Widget Management Interface™ is a MPA and you your Automated Widget Building Factory™ to know when to produce more widgets then you just got a new project. If it's an SPA then you just give the Factory a user and have it use the API.
Re: A single-page app is almost always worse than a multi-page app
#5I want to hug Greg for this article and especially this paragraph at the end: "Third, if you’re implementing a very complicated component then you can use React just for that component. For instance, if you’re building a chat box then there’s really no need to implement your login page in React."
You can totally do that, but I write React for the entirety of an app because it means not having two separate development flows for different features.
Making my login page driven by HTML and postbacks, rather than a straightforward REST(-ish) API talked to by an SPA, makes it nontrivially more difficult to establish the kind of separation of concerns necessary to then build a mobile application out of it (and as it happens, React is pretty useful there with React Native).
Re: A single-page app is almost always worse than a multi-page app
#6So, the OP argues that SPAs introduce unnecessary frontend state:
"I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult."
But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)."
I find the ad hoc jQuery+endpoint tangle much harder to reason about than something built with a front end framework and a more uniform API.
Re: A single-page app is almost always worse than a multi-page app
#7I think that the over-applicaton of the SPA architecture is one of those things that in the future will seem obvious, and we will wonder, "what were they thinking"? But when it is what everyone does, it is hard to question. It probably still has a few years before this becomes clear to management at the typical web shop, however.
Re: A single-page app is almost always worse than a multi-page app
#8Over the past year we replaced an Angular front-end with the author's recommendations: Turbolinks and Stimulus.js. With the pair, our app mostly feels like an SPA, but has the developer benefit of leaning on server-side rendering.
The experience was wonderful and highly recommended. I think it's perfect for small teams who are more productive with traditional/backend tech.
Re: A single-page app is almost always worse than a multi-page app
#9So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have…
This is true, the author seems to imply that it's somehow possible to always avoid complex UI state. Might be true for some UIs, but definitely not for all (e.g. a calendar UI would suck big time when rendered exclusively on the server-side).
Re: A single-page app is almost always worse than a multi-page app
#10Forcing a SPA just for the sake of SPA is overkill. But putting a group of related actions into a single page makes sense. Absolutely feel free to make a separate page for each separate group of UX actions/tasks. But let us not go back to the days of full page reloads on every mouse click.