Some questions about SPA UX
Ankush Thakur Aug 5
I came across SPAs a few months ago, but have never been able to wrap my head around them. I keep running into fuzzy guidelines and conflicting opinions, to the point where I've gotten turned off with the whole SPA thing. The one advantage I see is scenarios where complex interactive DOM operations are needed (Google Calendar?), which would be a nightmare to maintain in jQuery.
Anyway, on to my confusions, and I'm really looking for some perspective and help here.
SPAs help avoid "annoying" page reloads
Well, yes, but as long as we're talking about HTTP requests (or even WebSockets), delays are a part of life. If an SPA sends an Ajax request to a backend and for whatever reasons the whole thing takes five seconds, the experience, I believe, will be worse than a server-rendered page's (where at least the user can see a 'loading' icon).
SPAs provide (or aim for) a 'native app' experience
For the most part, yes, but again, where response waits are concerned, the UX can be just as bad, if not worse. I see many e-commerce websites, for example, where the search results page (with all types of filters) is rendered as an SPA, and changing a filter fires the SPA router and a new request is submitted. Now, if the response is delayed, the user will be left feeling stupid. If you show a loader, on the other hand, you've committed an SPA sin.
Another interesting argument for SPAs is that you can have a service worker (or even a simple
setInterval) that communicates with the backend and updates the app state regularly. It all sounds grand and dandy when dealing with 'to do' apps, but create something even moderately useful and you'll know what a nightmare it is going to be to never load a resource directly in response to user action. For instance, again, if there's an e-commerce search and the results contain one million products, we can't all pre-load them; and even if we keep caching them as the user navigates forward, there will come a time when the RAM will just explode. And even if there's more than enough RAM, how many products do you cache?
The Back button
This is something I see on dev.to as well. If you're on an article and navigate to another one, when you hit Back, there's no communication between the client and server. What if someone has commented on the article while you were away? Does that get handled (and updated) via WebSockets, or not at all?
I can understand how SPAs (now) provide predictable state containers and allow the kind of control over data that front-end devs only had dreamed of, but I fail to see what the extra effort accomplishes in most of the cases.
The Laravel community, especially the LaraCasts author Jeffrey Way, is mostly against SPAs and Flux (Elm) like central stores, at least. In the words of Jeffrey from a podcast interview: "Sure, it's cool, but . . . is it useful?"
Some ideas and insight will be greatly appreciated. What do you think of this whole mess? How do you manage your SPAs? Or maybe you just 'eschew obfuscation' and avoid SPAs? 🙏