score:11

tl;dr - if your server rendered page needs to be interactive on the client then you need renderToString, otherwise renderToStaticMarkup works fine.

Like with most things in programming, each has its trade-offs:

renderToString renderToStaticMarkup
This will attach some extra data-react* attributes to generated markup, react uses these when you run hydrate on the client to make the page interactive. The generated markup will contain no extra data-* attributes, it'll look like plain HTML. You can't make such a page interactive with hydrate.
The response size would be larger (how large, depends on the amount of markup your page contains) because of extra attributes added. The response size would be smaller.
You'll need react and react-dom in your client side bundles (for hydrating and making the app interactive. You don't need to include react or react-dom in your client side bundles (in fact you can get away with no JS on client side - non interactive pages). So you get the benefits of React for building UIs without the cost of added JS for such static sites
Usecases - isomorphic apps, server side rendering web apps for better UX / performance. Usecases - purely static sites (where you're not concerned about interactivity), non interactive blogs, when you want to use React for composing UI but don't want the added cost of including React in your JS bundles.

score:16

renderToString() is for when you want to pre-render on the server and eventually run the same React code on the client, re-using the DOM which was generated from the server markup instead of rendering from scratch.

The top-level component rendered this way includes a checksum the initial client render can use to determine that the DOM it would have generated matches what was sent from the server.


Related Query

More Query from same tag