Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: update info about how suspense works in frontend frameworks #904

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

pawelblaszczyk5
Copy link

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
Copy link
Owner

a-h commented Sep 8, 2024

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
Copy link
Author

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 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants