docs: update info about how suspense works in frontend frameworks

[pawelblaszczyk5]

Hello 👋🏼
I'm experimenting a lot with Templ recently. While being mainly frontend developer I'm recently using it at my job. While reading the docs about streaming I spotted this note about how suspense works in frontend frameworks. However, most of modern solutions don't work how described 😃

I'm not sure whether my proposed phrasing is conveying the message the best - I'm open about any suggestions that'd make the description easier to grasp. Also as mentioned I'm coming from frontend world so maybe different phrasing would be more suitable for most of templ developers.

Thanks a lot in advance

[a-h]

Thanks, I wasn't really trying to get the concept of how JavaScript SSR solutions work across, more trying to explain that with declarative shadow DOM and streaming no JS is required, and no additional HTTP requests are made, other than a single page load.

I get your point that in something like Next.js, the Next.js server would render the first pass of HTML, so instead of the server rendering:

<div id="app">
</div>

And then waiting for the JS to load and mount, you'd get the first rendering of the React component straight away, along with the snippets of JS required to populate missing content.

I think that adding another paragraph that explains that JS SSR frameworks take out the initial <div id="app"> loading step by rendering that on the server, but client-side JavaScript must still be executed, and an out-of-band HTTP request made by the JavaScript side to populate the placeholder, would make it a more complete comparison for those with a mental model that includes that.

[pawelblaszczyk5]

I'm mostly concerned about the SSR comparision, I'm not sure if I conveyed the message correctly but SSR frameworks in JS don't perform additional HTTP requests for that. And in some implementations you don't need to parse/execute the whole JS bundle to get it to work. That's the part worth correction for me the most.

I'm not sure whether comparing SPA to SSR in that manner makes sense, but that's less important if worded clearly 😃

[a-h]

I don't think this change adds clarity to the docs.

The point of this documentation section is to explain that, in React based apps, a placeholder will be rendered to the screen, then some JS executed to fill the placeholder.

The placeholder could be server-side rendered React, or client side rendered React, and it might be that JavaScript is sent from the server-side to the client side to complete the task. But some JS will run.

And at least one additional extra HTTP request is therefore required, since the client side JS will need to hit an API endpoint to pull back data to populate the placeholder section.

I think the extra complication of talking about closures etc. is unwarranted detail.

If you want to try again, maybe try adding a separate explanation for how JS SSR frameworks work as a :::tip:::?

[pawelblaszczyk5]

And at least one additional extra HTTP request is therefore required, since the client side JS will need to hit an API endpoint to pull back data to populate the placeholder section.

That’s not what happens in SSR JS frameworks and that’s what I’m trying to point out. Everything is streamed with one HTTP request and that’s why current description is misleading.

[a-h]

Ah, I see it was added in version 13 last year: https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming#streaming-with-suspense

I've added a note.