3 ms·

> Want to avoid re-rendering the whole page, when there’s only a small subset that actually needs to change? You can’t; it’s a “full page refresh.” This is whe

> Want to avoid re-rendering the whole page, when there’s only a small subset that actually needs to change? You can’t; it’s a “full page refresh.” This is where we a missing the middle ground in the debate. I do not consider a server rendered page that then uses HTMX (or "just" jQuery) to do partial refreshes or given areas of interactivity to be a SPA. So yes I can have my MPA and I can have partial content refresh and that does not require going all in on SPA frameworks.

Graffur 4y ago
Your point seems to be more of HTMX vs React rather than SPA vs MPA. With SPA frameworks you can deliver pages that can be accessed by the user (rather than just a single entry point). The difference becomes how the developer decides to build the application. Do they load all of the apps data on the first page load or do they retrieve it as the user browses around?
josephscott 4y ago
This. Call it MPA Foundation, or something. With an MPA foundation there are plenty of opportunities to make easy improvements to performance and page experience, while still having all of the page features work without JavaScript. Not because there are tons of users running around with JS turned off, but because every page load is running without JS until the JS finishes executing successfully ( as noted by many others ).
marcosdumay 4y ago
What's up with partial refresh that developers want it so much? Usually the only gain is that you don't have to reload and re-parse all the javascript that is there for doing partial refreshes.
jaredcwhite 4y ago
Exactly right! I find the SPA vs. MPA debate to be tedious, if not downright misleading, because it's perfectly possible build a web app that starts out as a basic MPA and then with (hmm, what's that term I'm looking for…wait for it…oh yeah!) *progressive enhancement*, you make it more and more SPA-like by loading in HTML fragments and making incremental DOM updates, updating the URL whenever possible to mirror backend state, etc. Heck, just with Turbo Drive alone, you can eliminate the "full-page reload" problem of MPAs with essentially zero (custom) JavaScript and it works great with static sites, full SSR frameworks, you name it. We desperately need better terminology around this stuff and the willingness to engage in nuance and see these it as a broad spectrum of various approaches you can mix 'n' match—sometimes all in the same project! Saying "oh this app's MPA, oh that app's SPA" will totally lead n00bs astray who aren't familiar with the production-level nuances involved.
woojoo666 4y ago
> I do not consider a server rendered page that then uses HTMX (or "just" jQuery) to do partial refreshes or given areas of interactivity to be a SPA. Why not? HTMX is itself a framework right? The distinction between SPA and MPA that the article gives (and that I agree with) is that MPA's delegate routing and page transitions to the browser. This naturally leads to less control (which makes the best case MPA worse than SPA), but also less complexity (which makes the average case MPA better than SPA)

Graffur 4y ago

Your point seems to be more of HTMX vs React rather than SPA vs MPA. With SPA frameworks you can deliver pages that can be accessed by the user (rather than just a single entry point). The difference becomes how the developer decides to build the application. Do they load all of the apps data on the first page load or do they retrieve it as the user browses around?

josephscott 4y ago

This. Call it MPA Foundation, or something. With an MPA foundation there are plenty of opportunities to make easy improvements to performance and page experience, while still having all of the page features work without JavaScript. Not because there are tons of users running around with JS turned off, but because every page load is running without JS until the JS finishes executing successfully ( as noted by many others ).

marcosdumay 4y ago

What's up with partial refresh that developers want it so much? Usually the only gain is that you don't have to reload and re-parse all the javascript that is there for doing partial refreshes.

jaredcwhite 4y ago

Exactly right! I find the SPA vs. MPA debate to be tedious, if not downright misleading, because it's perfectly possible build a web app that starts out as a basic MPA and then with (hmm, what's that term I'm looking for…wait for it…oh yeah!) *progressive enhancement*, you make it more and more SPA-like by loading in HTML fragments and making incremental DOM updates, updating the URL whenever possible to mirror backend state, etc. Heck, just with Turbo Drive alone, you can eliminate the "full-page reload" problem of MPAs with essentially zero (custom) JavaScript and it works great with static sites, full SSR frameworks, you name it. We desperately need better terminology around this stuff and the willingness to engage in nuance and see these it as a broad spectrum of various approaches you can mix 'n' match—sometimes all in the same project! Saying "oh this app's MPA, oh that app's SPA" will totally lead n00bs astray who aren't familiar with the production-level nuances involved.

woojoo666 4y ago

> I do not consider a server rendered page that then uses HTMX (or "just" jQuery) to do partial refreshes or given areas of interactivity to be a SPA. Why not? HTMX is itself a framework right? The distinction between SPA and MPA that the article gives (and that I agree with) is that MPA's delegate routing and page transitions to the browser. This naturally leads to less control (which makes the best case MPA worse than SPA), but also less complexity (which makes the average case MPA better than SPA)