New Question: JavaScript App Patterns

[SachaG]

I'm considering a new question to focus on rendering and architecture patterns:

---

JavaScript App Patterns

Which of the following architecture and rendering patterns have you used in the last year?

• Single-Page App Apps that run entirely in the browser
• Multi-Page App Apps that run entirely on the server, with minimal client-side dynamic behavior
• Static Site Generation Pre-rendered static content, with or without a client-side dynamic element
• Server-Side Rendering Dynamically rendering HTML content on the server
• Partial Hydration Only hydrating some of your components on the client (e.g. React Server Components)
• Progressive Hydration Controlling the order of component hydration on the client
• Islands Architecture Isolated islands of dynamic behavior with multiple entry points in an otherwise static site (Astro, Eleventy)
• Progressive Enhancement Making sure an app is functional even without JavaScript
• Streaming SSR Breaking down server-rendered content in smaller streamed chunks
• Incremental Static Generation Being able to dynamically augment or modify a static site even after the initial build

---

Notes:

• I know this is kind of a mix of different things, but I think it'd be impossible to separate all these into clean categories since they all interact with and complement each other.
• I'm specifically asking "which have you used in the last year" to avoid giving too much of an advantage to patterns that have been around for a while, like pure MPAs or SPAs.

[martinheidegger]

SPA, MPA, SSG,... Seem to be mutually exclusive, but Progressive Enhancement, Streaming SSR and Incremental Static Generation are but techniques that could be available or not for all of them?!

[eric-burel]

I'd clarify SSG , SSR as such:

• SSR: Dynamically rendering HTML content on the server at request-time

• Static Site Generation: Pre-rendered static content at build-time or anytime ahead of requests, with or without a client-side dynamic element

The distinction is strictly relative to when the request happens vs when the render data fetch.

Then, ISR is a tough one

You use a custom definition which I like but use Next.js wording which can be confusion.

ISR by Next: fetch data & render on 1 request and cache the rendered result DSG by Gatsby: fetch data at build-time & render on 1 request => data fetching and rendering are split. Next.js typically blends those steps (render always happen immediately after the data fetch) but it's not an obligation.

Fetching the data and rendering can be 2 different steps. Next.js chose to blend them (you define static vs per-request depending on how you fetch data) but it's not an obligation, Gatsby DSG splits those steps.

Why not calling that category "Static Augmentation" and quote both ISR and DSG as possible pattern?

I would say "augment or update" instead of "augment and modify", modify can be interpreted as Edge personalization

I would add "Server-side Personalization"

There are 2 flavours:

• altering the rendered HTML before sending to user, this is Eleventy approach or Next edge rendering
• rewriting the URL or redirecting to a specific page depending on the request. I18n is the most basic example, and the "Segmented Rendering" patterns I've formalized is a generalized version, for A/B testing, multi-tenancy and such (Vercel Platforms uses that for instance). They often happens at the edge for better performance but any proxy server can do that.

SSR

You might want to clarify "whether the content is later hydrated or not" => so this basically include Multi-Page Apps or PHP tor Django hat are traditional server-rendered apps but also hybrids that server-render the pages of an SPA like Next and friends

SSG

I would mention that HTTP caching a page available for multiple users also count as SSG, it's rendered ahead of requests or on 1st request and then served to user, so it's the same spirit.

[eric-burel]

SPA, MPA, SSG,... Seem to be mutually exclusive, but Progressive Enhancement, Streaming SSR and Incremental Static Generation are but techniques that could be available or not for all of them?!

Hmm I am not sure about that, a statically rendered Next.js page typically both falls into SPA and MPA category depending if you navigate from within the app or using the URL and uses SSG.

So it might be interesting to insist that those patterns are not necessarily exclusive and should be seen in their broader intepretation

[SachaG]

SPA, MPA, SSG,... Seem to be mutually exclusive, but Progressive Enhancement, Streaming SSR and Incremental Static Generation are but techniques that could be available or not for all of them?!

@martinheidegger even so I think that's fine, it doesn't really impact the question imo (it would be a multiple-choice question).

[SachaG]

@eric-burel how about adding:

• Edge Rendering Altering rendered HTML at the edge before sending it on to the client

re: ISR vs DSG, I called it "Incremental Static Generation" so I think it covers both ;)

[mhevery]

I would like to suggest:

• Resumabilty: Serialization of both application and framework state in a way that allows the framework on the client to continue execution where the server left off without re-executing the application code to recover the framework state. (Example of framework state: listeners, component boundaries, reactivity graph)

[SachaG]

@mhevery that's a bit long for the space I have available, my current definition was:

Serializing application state on the server in order to resume execution on the client

So how about:

Serializing application state on the server in order to resume execution on the client with no duplicated work

I think we can assume that "framework state" is part of the overall "application state" in that definition?

[mhevery]

Serializing application state on the server in order to resume execution on the client

The problem with the above definition is that many frameworks will say they do that. For example, NextJS does serialize the app state in __NEXT_DATA__.

For a framework to be resumable, it needs to serial Framework State (in addition to App state) Framework state includes things such as component boundaries, component props, listeners, reactivity graph, etc... And I think above definition falls short on that.

I think we can assume that "framework state" is part of the overall "application state" in that definition?

I don't think we can assume that. Because if we do most frameworks will claim that they do that.

It all comes down to how the FW recovers its INTERNAL state. Most do that by executing the application hence hydration.

How about this:

FW can process user interactions (execute listeners), without re-executing the components on the client to recover those listeners.

[SachaG]

OK then I suggest:

Serializing framework state on the server in order to resume execution on the client with no duplicated work

(of course Qwik also serialized app state, but since as you pointed out most frameworks can do that I think we can focus on framework state instead)

[mhevery]

Yes, I can get behind this definition. (some minor word smith)

Framework state is serialized on the server so that the client can resume execution without duplicate execution of code.

Feel free to edit more....

[eric-burel]

For each feature, is it worth quoting examples? Because people might use them unknowingly or better understand with an example. I fear that we may throw a lot of hard definitions into people faces making the question a tad scary.

SPA: using a framework with a JavaScript router, components that replaces "" tag MPA: using a framework that can render templates server-side, and/or that can procedes to code-splitting for each page SSG: "jamstack" frameworks that can output a built application SSR: using a framework that can render HTML server-side ISG: Gatsby DSG or Next ISR, or using a public HTTP cache in front of any SSR framework Edge Personalization: using a proxy server to redirect user to a personalized variation of the page, or render/alter directly at the edge

For instance, I don't know if it makes sense

@eric-burel how about adding:

• Edge Rendering Altering rendered HTML at the edge before sending it on to the client

Just on this: I really prefer "Edge Personalization". The word personalization is absent here but used a lot in the industry. + it would match the definition better, since it can be about altering a preexisting render

[SachaG]

@eric-burel I feel like if you use any of these patterns then you know what they're called. The more we try to explain them, the more we risk confusing people imo.

And I think "Edge Personalization" makes sense to me as well but I'd rather use the common term, which does seem to be "Edge Rendering".