But then I thought further and considered even more dynamic use cases:
- When layout depends on device characteristics (e.g. screen resolution, size, anything else) and the logic behind it can’t be expressed by media queries.
So what will happen if we manipulate layout at runtime after we have painted everything static from the server — exactly, it will recalculate and repaint components, potentially causing flickering.
Now I realise this potentially seamless isomorphic rendering can get lots of exceptions in non trivial applications. Which means that we, as developers, accept an additional task to always ensure that our components work both ways without side effects. Potentially we now need to test every state twice.
I am a lucky man. I wanted to dive deeply into performance analysis to compare SSR with frontend rendering. But this awesome guy has done it for me. Now to sum up his research, which seems to be very valid: Potential advantage of isomorphic rendering is very rare. It is the case when browser renders partially loaded html before it can complete the download.
I would still avoid isomorphic rendering when possible, but yes there is a valid use case for it today. In all other cases you should optimise the critical rendering path with other technics, especially inlining the initial data and optimizing perceptual performance of the first load e.g. by showing initially styled page or even placeholders.