Comment by pier25 | Hacker News Reader

Comment by pier25 | Hacker News Reader

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.

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?

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.

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.

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.

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

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?

Amazon app is actually a glorified webview.

Are you _amazon_? Nearly none of the companies have the scale of amazon, nor the needs of amazon. "It's proven many many times" is all in the eyes of the beholder, i'd say. Sure it might be slow if you are optimizing for 1ms latency, but that's not what 99% of the people do.

Google also doesn't use react. The ads stack is written in C++, for fb it's hack + c++, neither of which are the right tools for majority of use cases.

I am really struggling to understand your pov. I can throw together a whole app in asp.net MVC in days that takes weeks with react. Adding that extra layer of complexity of an API and duping the models adds a ton of work on top of everything.

But on top of that with C# and razor you've got strongly typed intellisense that just works which means rapidly building the templates which you just cannot achieve when making a spa.

Amazon is highly optimized for conversions on a single navigation. This is not representative of all web use cases. For ecommerce, I would agree with you. This is generally true of any site where a significant amount of the visits are load one page and then bounce to another site. SPA advantages don't help in your primary use case.

In other use cases, which there are plenty, different sets of rules dominate. There are plenty of places where SPAs provide a much better user experience than MPA.

I find SPAs simpler to do than MPAs if it fits the use case.

This is my experience as well. The SPA works best when the application is doing a bunch of stuff on the client side. If it has to make a bunch of trips back to the server, it's going to be a headache to debug.

To me, it's not a matter of performance one way or the other (server lag vs. overweight client). I'll deal with those issues when I come to them. What I care about is the ago-old problem of cohesion and coupling. I want the user-facing stuff in one place so that I can write and maintain it, closely cohering to itself and loosely coupled to the other parts of the system.

Even if this were true, you are sacrificing your end user experience for having a better development experience.

I'm a frontend dev and I work with React all day long. I still think MPAs and stuff like HotWire/Livewire/etc should be enough for like 90% of what we do. Being the last 10% offline first or Google Maps/ Figma level of interactivity apps.

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

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.

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.

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.

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.

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.

Reply on news.ycombinator.com