If you click on an <a> tag before the JavaScript has loaded and React has hydrated, the browser will do a full page load of the URL that you clicked on. Assuming that new page is also rendered on the server, it should work fine and feel just as good as if it was a traditional server-rendered HTML web site or if you had JavaScript turned off. (Of course, things that do require JavaScript for interactivity, like custom tooltips on hover, custom form validation, etc. won't work until the JavaScript has loaded.)

Just to add to the above, this is specifically when your pages are server-side rendered. Hydration is a concept of taking a server-rendered page and making it interactive with Javascript.

You can have your NextJS/React app server-rendered, and then users visiting a page will get the page. Clicking links within the application will use Javascript routing to load the part of the application that needs to be displayed (and prevent the default navigation from clicking said links). I think in practice it's more likely for users to fall back to default navigation which then relies on full server rendering when they have Javascript disabled, than it is because they've clicked before the front-end router has started working.

Also, before this thread I didn't realize React itself could be server-rendered (I thought that was the distinguishing point of Nextjs). Is it common to use non-next React for SSR?

> Is it common to use non-next React for SSR?

I believe so. I've encountered it used in several projects longer before Next.js (or at least before Next.js was so popular). The basic idea is really simple, on the server you just ReactDOMServer.renderToString(<App />) in Node and respond with the HTML string.

Of course, the devil is in the details. You probably need some conventions for statically determining what data needs to be loaded based on the URL (before you renderToString), some way of passing that global data to the client for React hydration, perhaps some API client that can handle making requests from both the client and the server, some system for handling HTML-specific concerns like meta tags and cache-control headers, etc. Frameworks like Next.js presumably make all these decisions for you!

What they mean is that, with a normal React SPA, the html content sent to the client will be little more than something like `<div id="react-app"></div>`. After the JavaScript loads, react hooks into this div and starts filling it with the html it generates for your app. With SSR, that div will be populated with html when it’s downloaded - this is the html that was rendered by the server. When the page is first rendered it will look like your app, but it’s totally static html. The JavaScript has to load and react has to take over managing the html within that div before any of the interactive content (think: button click handlers on so on) will be functional.

> Does this mean that one could make the page interactive with server side rendering, but it's not normally done?

It can be done, it is actually, how things were done a quarter of a century ago: server-side rendered content with tiny triggers for interactivity directly embedded in the code. In the next step, as complexity grew and as an attempt at separating concerns, you would send the content and along with it a bundle of code for interactivity (which may have been sent in the same request or as a separate resource). Then, we got frameworks. Technically, these could do this as well, but it doesn't match their basic pattern.