4 ms·
For the most part all you need to ask yourself is this: Must full page reloads be eliminated? (That's the real defining characteristics of SPAs) For 95% of b
by tylerjwilk00 8y ago
For the most part all you need to ask yourself is this:
Must full page reloads be eliminated?
(That's the real defining characteristics of SPAs)
For 95% of businesses a PWA with occasional full page reloads will be fine.
But for 5% of (mostly large) businesses, a kick ass SPA will be necessary.
- platz 8y agoThat's a great technique that I prefer - full page reload for links that have large screen changes i.e. page navigation - spa for page-specific interactivity i.e. filters, edits, updates Not having a client-side router strips out so much spa complexity. maybe for apps where you really need persistent state i will use a router/full-spa, but a lot of apps don't need full persistent state across all page navigations.
- jbergens 8y agoIn a way you are just moving the complexity back to the server code. I am not sure that helps in any way. The server will now have to have state or reload state on every request and that state could include many things that are not obvious like - what page are you on - which links should be shown in the menu - are there other things on the page that needs to be shown that has little to do with the current request-path
- collyw 8y agoA lot of that complexity belongs on the back end. Every front end page is likely to have a separate number of REST endpoints, so the code is effectively duplicated. In my experience keeping as much of the code on the back end eliminates a lot of complexity, though I am far more competent with backend technologies, but I have yet to see a SPA app that reduced complexity.
- deleted 8y ago[deleted]
- LiterallyDoge 8y agoSo what you're saying is, because you're lazy, you want the user to suffer.