Open hakenr opened 1 week ago
Stand by! A green dinosaur ๐ฆ will arrive shortly to assist.
original intent from the product team ... original meaning of SSR as static server rendering
That wasn't the only consideration when the current terminology was discussed.
Yes, the alternative is something like ...
We went with ...
IIRC, the choices we made are more in line with industry SPA terminology, but Dan will need to comment on that further.
We've all bugged out for the weekend. Let's take this discussion up next week with them.
... and just in case this was done, as I recall, to match industry terminology, I feel that we could at least have a remark in the Render Modes article to inform readers that the framework API uses "static server rendering" for "SSR"-named API if the PU agrees. I note in passing one spot where they seemed to have it match docs language in a comment ...
Stand-by ............ We'll be hearing from them soon.
I also saw that one instance - it's a comment - but in the API itself, it seems to be referred to as static server rendering everywhere.
No response yet ... but if we don't hear back by Friday afternoon, I'll mention it again.
In the Blazor Docs, the "SSR" abbreviation is primarily used for "server-side rendering" (covering both interactive SSR and static SSR). However, in the Blazor source code, "SSR" is more strictly used to mean "static server rendering," which appears to have been the original intent from the product team.
I believe we should standardize the meaning and usage of "SSR." If we don't, we risk creating confusing situations like this (configuring Blazor.Web.js startup):
https://github.com/dotnet/AspNetCore.Docs/blob/f679e7eb6af286aa96c13af46398d0e852f502fa/aspnetcore/blazor/fundamentals/startup.md?plain=1#L50
This won't be an easy change, but I still think it's worth reverting to the original meaning of SSR as static server rendering.
cc @guardrex