[Blazor] Inconsistence in usage of "SSR" abbreviation

[hakenr]

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):

• Place static server-side rendering (static SSR) options in the ssr property.

AspNetCore.Docs/aspnetcore/blazor/fundamentals/startup.md

Line 50 in f679e7e

* Place static server-side rendering (static SSR) options in the `ssr` property.

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

[github-actions]

🍂🎃🏮 Autumn Skies and Pumpkin Pies! 🥧☕🍂

Stand by! A green dinosaur 🦖 will arrive shortly to assist.

[guardrex]

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 ...

• No abbreviation for "server rendering"
• No abbreviation for "client rendering" (and "CSR" wouldn't be used to avoid "SR" for "-side rendering" because "client server rendering" isn't correct)
• SSR = static server rendering
• ISR = interactive server rendering

We went with ...

• SSR = server-side rendering
• CSR = client-side rendering
• static SSR = static server-side rendering
• interactive SSR = interactive server-side rendering
• No "static CSR"/"interactive CSR" distinction and "interactive CSR" is never used (just "CSR") because CSR is always interactive

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.

[guardrex]

... 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 ...

https://github.com/dotnet/aspnetcore/blob/main/src/Components/Web.JS/src/Rendering/BrowserRenderer.ts#L416

Stand-by ............ We'll be hearing from them soon.

[hakenr]

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.

[guardrex]

No response yet ... but if we don't hear back by Friday afternoon, I'll mention it again.

[guardrex]

UPDATE (10/29): Same deal here ... no response yet due to .NET 9 release work. I'll mention this again in this Friday's discussion.

[danroth27]

SSR is an existing term in frontend frameworks that means "server-side rendering". For JS frameworks this term is generally unambiguous, but in Blazor we have two forms of server-side rendering: static & interactive. To disambiguate which form of server-side rendering we are talking about we use the clarifying terms "static server-side rendering" and "interactive server-side rendering" both of which can be shortened to "static SSR" and "interactive SSR".

@mkArtakMSFT

[guardrex]

Thx @danroth27 ... but doesn't the framework indeed use "SSR" to mean "static server rendering" in API naming? It seems like I should add a brief remark on this for those devs that do look into framework API.

[danroth27]

Thx @danroth27 ... but doesn't the framework indeed use "SSR" to mean "static server rendering" in API naming? It seems like I should add a brief remark on this for those devs that do look into framework API.

I believe the framework generally uses SSR as it is traditionally used in the frontend javascript world, to refer to traditional server-side rendering. I'm not aware of any frontend javascript frameworks that use SSR to refer to "static server rendering". Unfortunate, saying just SSR for Blazor is unclear Because Blazor has two forms of server-side rendering: static & interactive.

[guardrex]

@danroth27 ... UPDATED after analyzing your last remark more carefully.

I believe the framework generally uses SSR as it is traditionally used in the frontend javascript world

I think that you're saying that "SSR" is not interpreted as "static server rendering" in the framework code (e.g., SsrStartOptions, SSRRenderModeBoundary, SsrComponentId, RenderSSRFormHandlingChildren, WebStartOptions's ssr) and code comments left by engineers.

Therefore, this should be closed as a 'won't-fix' item.

I did note along the way tho that Mackinnon seemed puzzled by the terminology conventions. I'm making a tracking note to discuss that further with him later.

[hakenr]

@danroth27 @guardrex I’m fine with closing this issue as "won't fix."

Just for the record: from the list above, only SsrComponentId doesn’t have a narrow meaning of "static." All the other instances (SsrStartOptions, SSRRenderModeBoundary, RenderSSRFormHandlingChildren, and WebStartOptions.ssr) are used only in a static context. 😇

On the other hand, components/Web/src/PublicAPI.Shipped.txt doesn’t contain any "ssr" usages. Only the WebStartOptions.ssr is a sort of public API (JavaScript) and is used in the docs.

All the other instances are private/internal implementation details - consider renaming them in the code. ;-)

[guardrex]

I have a feeling that this was why when Mackinnon saw what we did with the terminology he was like ... Are you sure about this? 🤣

consider renaming them in the code. ;-)

@danroth27 ... If it isn't going to change in the ref source, I can still place a passing remark at two strategic spots to surface what's going on when devs go look at the API.

In Blazor framework API of the [ASP.NET Core reference source in the `dotnet/aspnetcore` GitHub repository](https://github.com/dotnet/aspnetcore) and the [API documentation](/dotnet/api/), the abbreviation "SSR" is usually means "static server rendering," which is different from the ASP.NET Core documentation's use of "SSR."

... something like that. It would be placed where SSR is discussed in the Fundamentals > Overview and Render Modes articles.

Given your analysis, @hakenr, a similar remark can go where WebStartOptions.ssr is described.

I'm 👂 if you'd like me to knock up a PR on it, @danroth27.

[danroth27]

I'm 👂 if you'd like me to knock up a PR on it, @danroth27.

No, I don't think this is necessary. As already pointed out, SSR doesn't appear in our public .NET API surface area. SSR does appear in the typescript files in the dotnet/aspentcore repo used to implement the framework, but most users of the framework never see those.