4 ms·

Fantastic article and I totally agree with Nolan here: > I remain skeptical that we’ll get there, and even the best SPA would still have problems (complexity,

by pier25 4y ago

Fantastic article and I totally agree with Nolan here: > I remain skeptical that we’ll get there, and even the best SPA would still have problems (complexity, performance on slow clients, etc.), but I can’t fault people for trying. In the best case scenario someday building an SPA will be closer to building a mobile or desktop app. But even with batteries included (native widgets etc) those types of projects are inherently more complex than building a series of self contained pages. Of course a great SPA is always going to be better than a great MPA, but the effort to get there is huge. I interact daily with SPAs made by corps with big budgets and they aren't able to get it right either. Some examples: the Cloudflare dashboard, the Google Cloud console, etc. Just yesterday I was using the HBO Max web app and it was such a disgusting experience. It loaded 2MB of JavaScript for a simple password recovery form. And once logged in it was spinner after spinner after spinner. In some cases even throwing you out to others SPAs when navigating.

nightpool 4y ago
I'm curious: What problems do you have with the Cloudflare dashboard that seem to be SPA-related? I use it regularly, and the only problem I can think of encountering is that it never remembers my "desired location" when it redirects me to a login form—If I go to view the firewall graph (navigating from my browser URL bar with autocomplete based on history), it will send me to a login page and then dump me back onto the big "overview of all sites" page. But this is hardly a problem specific to SPA apps! Every multi-page app I've ever worked on had to implement some sort of "login_desired_location" cookie if they want to get this right, and very few of the apps I use ever get this right—regardless of page architecture. (The Google Cloud console is a complete nightmare, although I would argue that that's more for UX reasons then for SPA-specific ones—it seems honestly like the Google Cloud console is exactly as confusingly stateful and difficult to navigate as every PHP-based cpanel dashboard from the 90s: a hard bar to reach with any type of page architecture!)
- pier25 4y ago
  My main issue with the CF dashboard is that it's spinner-hell. It's fast, but there are spinners and layout shifts everywhere. Regarding the GC console, it has many UX issues, but regarding the SPA architecture my main complaint is that it's extremely slow and bloated. Every interaction takes seconds. Opening something on a new tab takes seconds. And there are spinners everywhere. I have to admit they recently pushed a new version that downloads less JS, but it's still pretty tedious to use.
- acdha 4y ago
  It’s slow - it’ll render in 1-2 on an M1 but then you get spinners or other progress bars for a while as various API calls return (each GraphQL call is like 5 seconds). The report graphs are similar: in theory that could be faster but in practice they’re not more responsive than late-90s PHP scripts were and the main advantage interactivity-wise is that you can update multiple filters in the time it takes the results to load. This is generally okay, but I would use it as exhibit A for the argument that you aren’t going to see a performance win simply from using an SPA or GraphQL. You might find this approach lets you get further if you put serious effort into it but that’s not cheap or a given.
tehlike 4y ago
I actually find building SPAs much easier than building MPA from complexity and performance pov. I have done ASP before, then ASP.NET Webforms, then ASP.NET MVC, then angular, then react. I find react the easiest, and cleanest way to do the SPA stuff, and it's much easier to get anything done with it than building MPAs.
- pier25 4y ago
  The performance angle of SPAs has been proven wrong many times. If SPAs had better perf than MPAs, I can assure you Amazon (the store) would be an SPA. But SPAs are notoriously slow, specially if built with React. Amazon tested React and it was too slow for them so they kept using Java for SSR + jQuery. I think they removed jQuery recently, but keep using the same approach of SSR + sprinkled JS. As for dev complexity, I'd be very surprised if that was the case. Are taking into account writing the backend code or only the frontend? What about client-side data caching? What about spinners? What about mismatched version of the app for users that don't close their tabs all day long? Etc. Etc. Yes I know all problems with SPAs have solutions. But that's the point the article is making: you have to solve it.
  - com2kid 4y ago
    > If SPAs had better perf than MPAs, I can assure you Amazon (the store) would be an SPA. What technology does the Instragram in-app shopping experience use? Because whatever that is, it is 10x better than the Amazon app. Amazon's websites, mobile and desktop, and app, are all horrible compared to the competition. Slow, hard to navigate, long load times, I wouldn't use Amazon as a point of reference for anything.
    - pier25 4y ago
      I don't use Instagram so I can't compare. I don't use the Amazon mobile app either. What I do know is that the Amazon mobile website, while ugly and outdated in many respects, runs ways better in my crap Android phone than probably 99% of SPAs. I don't know, but it's probable the "Instragram in-app shopping experience" has better UX. Although that's not really what we're discussing here, are we?
oblak 4y ago
The quote you shared is utter non-sense. I have built SPAs running on devices so underpowered, you wouldn't believe. Single core, 512MB RAM, no GPU. And with a browser running on on top of all kinds of other crap. Right tech for the job. Where "the job" could be anything. Considering what modern browsers run on.
- pier25 4y ago
  The context of that quote is mostly about dev complexity. I've built small SPAs that perform great on low powered mobile devices, but that's not typically happens in practice. Even on desktop, most SPAs are super bloated and slow.
  - oblak 4y ago
    Eh, but one could just as easily say "non-SPA" websites aren't all that great either, see? The real bloat is the 15 trackers and ad platforms, imho. I am not advocating for SPAs, btw. Personally, I mostly browse with JS disabled. Complexity takes many forms. The last thing many* complex back ends need is serving a plethora of clients instead of data. * See, I can do play that game, too. Coming up with "data" in support of my argument.
weego 4y ago
In the best case scenario someday building an SPA will be closer to building a mobile or desktop app This is the worst case scenario for everyone. Why does this industry have a pre-occupation with trying to increase complexity of the simplest things over time?
- pier25 4y ago
  Making an application where you have full control over what's going on is never going to be simple. But at least when doing desktop/mobile dev you typically have a framework that leverages a lot of stuff for you. This framework is totally absent when doing SPA today.

by pier25 4y ago

nightpool 4y ago

I'm curious: What problems do you have with the Cloudflare dashboard that seem to be SPA-related? I use it regularly, and the only problem I can think of encountering is that it never remembers my "desired location" when it redirects me to a login form—If I go to view the firewall graph (navigating from my browser URL bar with autocomplete based on history), it will send me to a login page and then dump me back onto the big "overview of all sites" page. But this is hardly a problem specific to SPA apps! Every multi-page app I've ever worked on had to implement some sort of "login_desired_location" cookie if they want to get this right, and very few of the apps I use ever get this right—regardless of page architecture. (The Google Cloud console is a complete nightmare, although I would argue that that's more for UX reasons then for SPA-specific ones—it seems honestly like the Google Cloud console is exactly as confusingly stateful and difficult to navigate as every PHP-based cpanel dashboard from the 90s: a hard bar to reach with any type of page architecture!)

pier25 4y ago
My main issue with the CF dashboard is that it's spinner-hell. It's fast, but there are spinners and layout shifts everywhere. Regarding the GC console, it has many UX issues, but regarding the SPA architecture my main complaint is that it's extremely slow and bloated. Every interaction takes seconds. Opening something on a new tab takes seconds. And there are spinners everywhere. I have to admit they recently pushed a new version that downloads less JS, but it's still pretty tedious to use.
acdha 4y ago
It’s slow - it’ll render in 1-2 on an M1 but then you get spinners or other progress bars for a while as various API calls return (each GraphQL call is like 5 seconds). The report graphs are similar: in theory that could be faster but in practice they’re not more responsive than late-90s PHP scripts were and the main advantage interactivity-wise is that you can update multiple filters in the time it takes the results to load. This is generally okay, but I would use it as exhibit A for the argument that you aren’t going to see a performance win simply from using an SPA or GraphQL. You might find this approach lets you get further if you put serious effort into it but that’s not cheap or a given.

tehlike 4y ago

I actually find building SPAs much easier than building MPA from complexity and performance pov. I have done ASP before, then ASP.NET Webforms, then ASP.NET MVC, then angular, then react. I find react the easiest, and cleanest way to do the SPA stuff, and it's much easier to get anything done with it than building MPAs.

pier25 4y ago
The performance angle of SPAs has been proven wrong many times. If SPAs had better perf than MPAs, I can assure you Amazon (the store) would be an SPA. But SPAs are notoriously slow, specially if built with React. Amazon tested React and it was too slow for them so they kept using Java for SSR + jQuery. I think they removed jQuery recently, but keep using the same approach of SSR + sprinkled JS. As for dev complexity, I'd be very surprised if that was the case. Are taking into account writing the backend code or only the frontend? What about client-side data caching? What about spinners? What about mismatched version of the app for users that don't close their tabs all day long? Etc. Etc. Yes I know all problems with SPAs have solutions. But that's the point the article is making: you have to solve it.
- com2kid 4y ago
  > If SPAs had better perf than MPAs, I can assure you Amazon (the store) would be an SPA. What technology does the Instragram in-app shopping experience use? Because whatever that is, it is 10x better than the Amazon app. Amazon's websites, mobile and desktop, and app, are all horrible compared to the competition. Slow, hard to navigate, long load times, I wouldn't use Amazon as a point of reference for anything.
  - pier25 4y ago
    I don't use Instagram so I can't compare. I don't use the Amazon mobile app either. What I do know is that the Amazon mobile website, while ugly and outdated in many respects, runs ways better in my crap Android phone than probably 99% of SPAs. I don't know, but it's probable the "Instragram in-app shopping experience" has better UX. Although that's not really what we're discussing here, are we?

oblak 4y ago

The quote you shared is utter non-sense. I have built SPAs running on devices so underpowered, you wouldn't believe. Single core, 512MB RAM, no GPU. And with a browser running on on top of all kinds of other crap. Right tech for the job. Where "the job" could be anything. Considering what modern browsers run on.

pier25 4y ago
The context of that quote is mostly about dev complexity. I've built small SPAs that perform great on low powered mobile devices, but that's not typically happens in practice. Even on desktop, most SPAs are super bloated and slow.
- oblak 4y ago
  Eh, but one could just as easily say "non-SPA" websites aren't all that great either, see? The real bloat is the 15 trackers and ad platforms, imho. I am not advocating for SPAs, btw. Personally, I mostly browse with JS disabled. Complexity takes many forms. The last thing many* complex back ends need is serving a plethora of clients instead of data. * See, I can do play that game, too. Coming up with "data" in support of my argument.

weego 4y ago

In the best case scenario someday building an SPA will be closer to building a mobile or desktop app This is the worst case scenario for everyone. Why does this industry have a pre-occupation with trying to increase complexity of the simplest things over time?

pier25 4y ago
Making an application where you have full control over what's going on is never going to be simple. But at least when doing desktop/mobile dev you typically have a framework that leverages a lot of stuff for you. This framework is totally absent when doing SPA today.