*>Stuff like filtering search results is very easily accomplished by a MPA with ...

ryanbrunner · 2024-01-07T14:57:50 1704639470

> But the "MPA to another results page" causing an HTML reload with a flickering blank screen is a jarring UI experience.

Pretty much every modern full stack framework includes approaches to do partial renders and / or DOM morphs of server generated HTML responses, eliminating the full-page refresh effect.

www.mcmaster.com seems to utilize this to some degree, actually - while yes there are JSON responses, there are what appear to be HTML partial responses as well that are presumably injected on the page. In any case, everything on that search engine would be trivially accomplished using a server rendered HTML approach without needing to utilize a SPA. It's actually a great example of something that would work great with progressive enhancement - the search bar can start as a simple input that leads to full page search results, the navigation can do a full page refresh if the partial page refresh JS isn't available for some reason. Javascript can make it better without being a requirement.

A good rule of thumb is that if an interaction existed at roughly the same fidelity during the Web 2.0 days, it's not something that requires a SPA framework. Typeahead search results and categorized product listings existed and were functional to the level of the site you linked back then.

jasode · 2024-01-07T15:21:08 1704640868

>partial renders and / or DOM morphs of server generated HTML responses, eliminating the full-page refresh effect. www.mcmaster.com seems to utilize this to some degree, actually - while yes there are JSON responses, there are what appear to be HTML partial responses as well that are presumably injected on the page.

Uhm... yes?!? The behavior you listed is exactly why I gave you that McMaster example. So I guess I'm a little confused. In any case, your comment matches up with the wikipedia definition of SPA (https://en.wikipedia.org/wiki/Single-page_application):

>A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of a web browser loading entire new pages. The goal is faster transitions that make the website feel more like a native app.

An alternate way of interpreting your reply to me is if you also categorize McMaster's website behavior as a form of "MPA". In other words, you classify McMaster's loading of new HTML fragments and rewriting DOM as "multiple pages". I've not heard others define MPA in this way.

>, everything on that search engine would be trivially accomplished using a server rendered HTML approach without needing to utilize a SPA. It's actually a great example of something that would work great with progressive enhancement - the search bar can start as a simple input that leads to full page search results, the navigation can do a full page refresh

Yes, we've already agreed about it being technically trivial. The issue is end user's preferred UI experience. Users don't want the "page refresh/reload" even though it's trivial.

ryanbrunner · 2024-01-07T17:56:02 1704650162

I think a lot of the time "SPA" vs "MPA" essentially actually means "does the client largely render it's own HTML" or "does the server render HTML and the client just displays it". Whether it displays that with a full page refresh or by injecting HTML via Javascript does not in practice matter. The idea of using AJAX to render HTML fragments to increase interactivity predates the term "SPA" by about a decade.

That's not really strictly the same thing as what the acronyms SPA and MPA, but in reality, people refer to a Rails application that uses large amounts of Hotwire as a "MPA" (even if it never results in full page refreshes and often doesn't even feel like navigating pages) and things built with tools like React as "SPAs" (even if you're perfectly capable of navigating between pages and getting React rendered by the server until the client takes over routing.

If your definition of "MPA" is "every interaction requires a full page load", it's a pointless discussion, because that's not really the reality of development even with "MPA" frameworks like Rails or Phoenix (I can't really speak to stuff like Laravel, but I'm sure they have an equivalent)

Maybe a good way to think about it is that the fundamental interaction model of frameworks like Rails is that they're built around the concept of the server returning new pages on navigation, and optimize that to provide a better experience, and SPAs are designed around the idea of a single web page visit instantiating an application at which point the client is control of navigation, but they optimize that to provide a better user experience (i.e. server side rendering of pages on first load).

jasode · 2024-01-07T21:24:29 1704662669

>I think a lot of the time "SPA" vs "MPA" essentially actually means "does the client largely render it's own HTML" or "does the server render HTML and the client just displays it".

It seems like there was already terminology of CSR-vs-SSR (client-side vs server-side rendering) to differentiate that so there was no need for SPA-vs-MPA to overlap with CSR/SSR to try and make the same distinction.

>Whether it displays that with a full _page_ refresh or by injecting HTML via Javascript does not in practice matter.

It seemed like the 'P' in SPA-vs-MPA is literally about the Page(s) being reloaded. It's "single page" or "multiple pages". That's why developers like to clarify that Next.js -- even with SSR HTML hydration of various subpages -- is still an SPA because the page on the client-side browser isn't reloaded. I just did some skimming of various "SPA vs MPA" search results and none seemed to use those acronyms as a way to classify CSR-vs-SSR. (https://www.google.com/search?q=spa+vs+mpa)

I'm also not clear how you classify Mcmaster.com ? Is it an MPA to you?

>If your definition of "MPA" is "every interaction requires a full page load", it's a pointless discussion,

No I'm not saying every interaction. I was responding to your original suggestion of "MPA with query parameters to a results page" ... and showing how McMaster.com search filters do not work the way you recommend it should. Each click of navigation and filters triggers a JSON payload and dynamically rebuilds the DOM tree. The browser's performance.timing.loadEventEnd property value does not change.

troupo · 2024-01-07T15:00:43 1704639643

> The issue isn't what's "easy" to implement. Instead, users prefer a fluid and responsive UI.

Most SPAs can't give you that either.

giantrobot · 2024-01-07T16:54:40 1704646480

> But the "MPA to another results page" causing an HTML reload with a flickering blank screen is a jarring UI experience.

This is the worst and dumbest excuse for SPA bullshit. It's not jarring. You'll get over it. It's a fraction of a second where your devices is obviously doing a thing.

Web devs love the word "jarring" like it's some world shattering visual effect. SPAs break all the time in dumb-ass ways that are way more jarring and experience breaking than a page load.

jasode · 2024-01-07T17:41:40 1704649300

>Web devs love the word "jarring" like it's some world shattering visual effect.

I've never been a web dev. I'm just explaining why the typical mainstream end users who don't have the same patience as HN-type techies (who more happily accept MPA) do not like the discontinuous UI of reloading pages.

Another example of that SSR MPA page reload/refresh would be old Mapquest before 2006. Screenshot: https://www.e-education.psu.edu/geog160/sites/www.e-educatio...

Each click on North/South/East/West buttons and Zoom In/Out blanked out the entire page and loaded a new page to shift the map viewport. This was a suboptimal UI experience for the typical user. I concede it wasn't "jarring" to you but it was to a lot of users -- especially compared to a CDROM maps experience. Example video of a smoother maps UI experience circa ~2000 from Microsoft CDROM desktop software without "blank reloading pages" to move a map around and change zoom levels: https://www.youtube.com/watch?v=4YO_KGdsUm4

The Mapquest "MPA page reloads" from 2006 was a UI that was less smooth than the Microsoft Streets CD software from 2000.

In 2005, when Google launched Google Maps with extensive usage of Javascript live-loading map tiles to provide smooth scrolling without reloading pages, end users liked that UI because it felt more interactive. In response, Mapquest also eventually switched away from the old-style SSR MPA page reloads: https://techcrunch.com/2007/10/12/exclusive-mapquest-plays-c...

The 2005 SPA-style of Google Maps just gets the UI back to what users already experienced in 2000 with desktop software. The SSR MPA page reloads was something that end users endured with Mapquest but it wasn't actually the UI they really wanted.

I'm not advocating the web devs use SPA (or SPA frameworks). Instead, I'm saying that responding with "SPA websites can be redone as MPA and it's trivial" is saying something that's true but still doesn't actually address the issue that mainstream endusers don't like the discontinuity of MPA type of UIs. That's the subthread I was addressing: https://news.ycombinator.com/item?id=38901249

E.g. McMaster.com is not a "web app" like Figma/Photopea but users prefer the SPA-style UI of that parts catalog website.