re: Some questions about SPA UX VIEW POST

FULL DISCUSSION
 

Hi Ankush, only built one SPA and a half here so I'm definitely not an expert but I like them so I'll try to give you my perspective.

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

The user experience doesn't have much to do with SPA/non-SPA in this regard. It's just up to you to show tell the user that tha SPA is loading something. It's quite easy, most CSS frameworks have a loading state for their components or a loading div that covers the container. You can also use progress indicators or placeholders, depends on your UI. There's a lot of content regarding loading states on Google.

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.

I'm not sure why showing any loading state is a SPA sin. I'm sure there are SPAs that are bad out there but I don't think it's an intrinsic defect, it's just that most people are bad at UX :-D

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?

Again, how's this an issue of SPAs instead of bad programming practice? It's going to be the same bad experience if, with a server side rendered page, I send to the user ALL the results :D And why you should you cache everything?

BTW dev.to is a SPA that makes use of service workers (so technically a PWA), outside the response of user interaction, maybe you could take a look when the code is going to open sourced in three days :-)

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?"

Wait, that's weird. Laravel and its community is one of the reasons why Vue.js has so much adoption for example. Granted that different people in a community can have different opinions, bust still... :-)

Some ideas and insight will be greatly appreciated. What do you think of this whole mess? How do you manage your SPAs?

I don't think it's a mess. It's definitely a more complicated approach then "render a table server side, send it to the user and sprinkle the page with jQuery" because JS tooling and frameworks are a lot to take in but I don't think SPAs are a mess. It's just another paradigm of creating a web app, it might be right or wrong depending on the case.

My one and a half SPAs are quite similar, they are both in Vue, with a router, the latter one has a central store (Vuex), the first one is completely driven by the API (I didn't deem the store necessary at the time).

Or maybe you just 'eschew obfuscation' and avoid SPAs?

What does "eschew obfuscation" mean? :-)

 

Hey, thanks for the reply! Here are my thoughts:

The user experience doesn't have much to do with SPA/non-SPA in this regard. It's just up to you to show tell the user that tha SPA is loading something.

Well, if I show a loader on every page, the distinction between an SPA and a server-rendered app vanishes. The 'smooth' transitions are definitely the part of SPA UX (please see the new section I added to my post: 'The Back button').

Wait, that's weird. Laravel and its community is one of the reasons why Vue.js has so much adoption for example.

They love Vue.js because it can included like jQuery and isn't weird like React. It doesn't have any fundamental connection to SPAs.

BTW dev.to is a SPA that makes use of service workers (so technically a PWA), outside the response of user interaction, maybe you could take a look when the code is going to open sourced in three days :-)

I noticed that dev.to progressively loads HTML for articles mentioned on my feed when I scroll down, or even when I do nothing. I guess server workers are neat, but the question of when to update and how to represent it (UX) remains, at least for me (again, could you take a look at 'The Back button' section and tell me what you think of it?).

What does "eschew obfuscation" mean? :-)

Well, it's a sort of joke I came across some time ago. It's a more complicated way of saying 'avoid complexity'. 😄 Maybe I should remove this reference, or maybe not . . .

 

Well, if I show a loader on every page, the distinction between an SPA and a server-rendered app vanishes. The 'smooth' transitions are definitely the part of SPA UX (please see the new section I added to my post: 'The Back button').

I disagree with that. The only real required difference between a SPA and a traditional web app is that the SPA avoids page loads. Ideally, a regular user shouldn't notice nor care whether the app is single page or not.

You talk about the SPA UX, but I don't think there's anything particularly different in UX considerations between SPA and traditional web apps. Smooth transitions enhance any app's UX. SPA can be (but not necessarily are) a way to achieve smooth transitions.

Usually, smooth transitions mean fast transitions. The promise of SPAs is that by only loading data, you avoid the extra time that it would take for the browser to parse the html, css and scripts for the new page and therefore the transition is faster. That is entirely different to no loaders should be shown ever. Ideally you want the transition to be so fast that the loader is never shown, but if the request takes a noticeable time (there could be a hundred reasons, slow connection for instance), you definitely want to show a loading state to the user instead of just leaving the app unresponsive.

Thank you, thank you for your thoughts. This is really reassuring:

The promise of SPAs is that by only loading data, you avoid the extra time that it would take for the browser to parse the html, css and scripts for the new page and therefore the transition is faster.

But then again, could you please address how to handle the Back button. Dev.to doesn't reload the content when I hit back, so what if there's an update on the page?

That's just the way dev.to is built. Nothing would prevent a SPA from requesting the data again when going back to the previous page.

In fact, requesting the data again would be the default behaviour, if you want to cache your pages like dev.to does, you need to specifically build it. Otherwise, the app doesn't care how it got to the current page, whether the user loaded the page there through a bookmark, a link within the app, the back button... It just requests the relevant data and renders the page.

Also, I think that the dev.to behaviour is not specific to the back button, I've noticed that articles and pages I've visited recently aren't updated when I visit them again, so I doubt that the caching is specific to the back button.

In fact, requesting the data again would be the default behaviour, if you want to cache your pages like dev.to does, you need to specifically build it.

Honestly, what a relief. I avoided building SPAs for the last few months because I thought something was wrong with my approach. 😅 Thanks a lot, good (sir? madam?)!

 

I'm not UX expert though, what I was trying to say is that what you attribute to SPAs intrinsically to me seems it's more about UX issues than the technology itself.

Well, if I show a loader on every page, the distinction between an SPA and a server-rendered app vanishes. The 'smooth' transitions are definitely the part of SPA UX (please see the new section I added to my post: 'The Back button').

Well, it can still be faster even with that.

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?

Don't know about the details of dev.to yet, but SPA doesn't mean you never ever hit the refresh the button though.

mobile.twitter.com AFAIK is more or less like that. If you go back and you end you in the homepage, the homepage will pile up the new tweets and push them at the top of the feed.

But keep in mind that not all SPAs are the same.

I'm still convinced what you highlighted in your post is more of a design/UX issue than a technology shortcoming :-)

Thanks for your comments. Yes, looks like I've made it appear like a criticism of SPAs than questions about UX. But I disagree that this is a pure UX question -- avoiding page reloads is impossible in a traditional app but is (almost always?) possible in an SPA so there's definitely UX difference arising out of technological differences.

But keep in mind that not all SPAs are the same.

That's a relief to hear. So, my SPA can have spinners on every page, whether you navigate away from it or to it? 😊

code of conduct - report abuse