Should we maybe not compare MPA and SPA?

[Fuzzyma]

I am having trouble to get around the glossary entry here:

framework-tracker/packages/docs/src/pages/glossary.astro

Lines 31 to 33 in 8606046

	<strong>Navigation model</strong> — Does the browser perform a full page load
	for each route (MPA), or does JavaScript intercept navigation and update the
	page in-place (SPA)?

For me, this is not realistic. What is described here is good old server rendered pages and not necessarily a multi page app.
Afaik every meta framework has some form of link primitive that keeps the current site open while the server renders the next one and navigates over smoothly.

A fresh page load would mean to use <a> but nobody ever does that in a meta framework (besides sveltekit but sveltekit handles all <a> the same as e.g. nuxt does <NuxtLink> so its not even a fair comparison at this point because sveltekit will NOT do a fresh page load).

I would argue that the difference between SPA and MPA is critically that an MPA has multiple pages that are all rendered on the server without requiring to load a whole chunk of js for client side rendering and not so much of it is a fresh page load.

But then - we are really just measuring SSR again. Thats why I find the split of SPA to MPA kinda pointless.

WDYT?

[AlexanderKaran]

@43081j Tagging you in this as it came up today, checking the Vue set-up for issues.

@Fuzzyma So we don't compare SPA to MPA; we just have tests in SPA mode and in MPA mode. However, I think you hit a key point here.

Let's start with SPA. James asked for these because many SPAs are still built today. Some frameworks even have an SPA mode or can be configured to be client-side-only.

However, you hit the nail on the head with MPA. Is this the right title to put the tests under? As you're right, most frameworks render on the server; client-side navigation takes over when you click a link to the next page. It might render on the server, but you won't get a full page load like our glossary says: https://framework-tracker.pages.dev/glossary/

I think our glossary needs to change, and/or so does the title for the MPA tests.

[Fuzzyma]

I agree that we need to measure SPA time. But what we are measuring here is client side rendering while our example the MPA uses server side rendering

I am aware that you can use SSR in SPAs as well (and you can totally use client side rendering in MPAs). Thats why I find the split missleading.

We should test full client side rendering vs full server side rendering and not SPA vs MPA imo.
Thats a clear cut, possible in all frameworks, and easy to verify

[43081j]

That makes sense to me.

What you're calling "full client side rendering" is what an SPA used to be, and "full server rendering" an MPA.

Frameworks have just changed the definition over time with more granular types of rendering, mixing and matching.

So I think I'd be happy to reword around those terms instead of plain SPA/MPA.

[AlexanderKaran]

Great so SPA tests becomes client side rendered and MPA becomes Server Side Rendered?

Things can still be client side in the SSR set up? Maybe:

Is Server Side Rendered with ... x (default set up for most)

Or maybe Server Side Rendered with a subtitle?

[Fuzzyma]

That's what I meant. Multipage apps can be fully client-rendered and single page apps can be fully server rendered.
That's why I don't like the comparison of spa and mpa.

I would even go a step further and just have the same app once client side rendered and once server rendered. Doesn't that already give us all the metrics we want?

[AlexanderKaran]

@Fuzzyma Yes, I agree. I still think a little nuance will need to be explained in the title, sub-title and description of the tests.

I will tag you and James in the few PRs to make the changes and then we can make sure it is all covered by my changes.