Clarify "SSR compatibility" of components in documentation?

[strlns]

I just stumbled over #756 .

Even Geist UI docs uses the Tabs component for navigation links.
But these links are not in the initial HTML and only ever rendered on the client.
I understand that the visual effects and the documented original purpose are not possible without JS enabled.

But I also expected the tab headers to at least render in the initial HTML, since the docs state

All Components of Geist UI are compatible with Server Render. In fact, the document you see now is rendered by the server.

The docs page has many components that only render on the client, exept for a skeleton or blank space:

• sidebar navigation
• main navigation
• code snippets

The sentence in the docs probably means that SSR doesn't error out with hydration errors, and that users with JS and a stable connection won't see major layout shifts – which is great.

But I think the sentence could still be clarified to reflect that some components do not degrade gracefully without JS and in fact are not rendered on the server (not the same as "compatible with SSR", I know).

Geist UI docs is a great example for this.

I like the UX of the docs page and it does not feel like a major problem, but maybe it has implications for slow connections and SEO?

Maybe components which only render their content on the client despite not needing network calls could have some kind of hint about this in their documentation?

Basically this also means that
#517

can be a bad idea depending on priorities, doesn't it?

TL;DR:
Maybe it's just me, but I'd like this to be more clear.

Something like "all Geist-UI components are compatible with SSR, but many of them render their actual content on the client"?

Hm, doesn't sound great either.

I see that all the JSON is easily delivered in SSG contexts which leads to a really fast page load and should guarantee there are no major problems with SEO and the like.

[strlns]

On a similar note, it seems like the documentation doesn't fully explain why geist-ui can cause hydration problems in SSG context.

Since the useMediaQuery hooks are not an option in SSG context, it would be great to have
a docs page similar to this one from MUI:
https://mui.com/material-ui/react-use-media-query/#server-side-rendering

I just realized today that I simply can't use a lot of features as soon as I need media queries.
(e.g. margin and padding utility props: for SSG they have to be the same for all screens, otherwise I need external CSS).

This is not meant as a complaint.

Maybe I could help improving the docs, or I am fundamentally misunderstanding something?

My current workaround is to just my own CSS wherever I need media queries.

This starts already with the <Page> object, which has styles set via inline styles that I need to make responsive without relying on SSR and CSS-in-JS.

This topic overlaps with my other opened discussion #826

[strlns]

Maybe this duplicates parts of #747 , especially the media queries part.