Isomorphic rendering.

Recently javascript frameworks (react, ember) started to add optional server side rendering (SSR) support. The idea is to render everything on the backend when loading the page first time, but everything after that is rendered on the frontend.

It didn’t seem to be a bad idea at the first glance to me. But recently we have got this issue about the SSR support in JSS.

The fundamental problem is that everything delivered from server is static. It can’t rely on javascript and DOM (not considering inlined javascript). Which means also styles can’t be JSS any more, they need to be converted to pure CSS, plagued by issues JSS is trying to fix in the first place.

Dynamic layouts

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.
• When javascript layout engine is used, such as famo.us or GSS. Also recently I became a huge fan of constraint based layouts and animations .

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.

Maintenance

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.

Performance

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.

However there is valid use case. (Thanks to Dan for pointing this out.) Imagine you are building a content website using react or any other bigger js framework. Now imagine you are on a mobile device with bad internet connection. It can potentially take multiple seconds until you can actually read something if you need to load and evaluate 200kb javascript first. For this use case I would even consider not loading the dynamic part at all.

Conclusion

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.