I believe you’re correct: there are many subtle trade-offs and limitations like this that must be dealt with when implementing SSR.
From this article on React SSR:
- Make sure you don’t reference window or document
Your React components will now be rendered by your node backend. And your node backend doesn’t have the window or document global variable. That could lead to errors like this on server side:
window is not definedIf you get a similar error, you can put the code referencing the missing variable in an if statement like this:
if (typeof(window) !== "undefined") { window.localStorage = ... }
So an SSR approach for Elm would need to deal with the fact that some effect handlers would not be supported in the pre-rendering environment.
As to the specific question of elm-ui, if I were implementing an app that I wanted to have SSR, I would be happy to accept the constraint that the content’s layout must work without JavaScript (perhaps doing progressive enhancement with JS for non-essential features).
In an ideal world, where Elm had first-class support for SSR, I would imagine that effect handlers that depended on the window object might support returning a result like NotSupportedOnServer, which you could handle as appropriate in your app.