Exploration for Server-side Rendering

I’d say that’s an untenable restriction. It is very common for Elm apps to init into a “Loading” state, which then fetches content from the server. Only once that content is loaded and the view updated is the view content-complete, and it’s that view that we want to send from the server, so that search engines and clients without JavaScript can access the content.

If the Elm runtime were going to attempt to pick a sensible moment to declare the view “stable”, I’d say it would be the first view after all of the commands triggered by init have run, the resulting updates processed, and the first view after that rendered. But even that would be full of edge-cases.

Server-side rendering an empty shell with a loading spinner is not very useful.

@rupert the “SVG canvas” type of application you’re thinking of doesn’t strike me as a particularly good candidate for server-side rendering. One local business that depends heavily on SSR, for example, is a job search website, which has category pages that initially list the newest jobs in that category, but which provide a rich set of filtering controls that you can apply and have the search results update (with each filter state having its own bookmarkable/shareable URL). That company considers it vital to have those job listing pages (as well as the individual job pages) load very fast (because search engines rank fast-loading pages higher), with complete accessibility to search engines and people with disabilities.