Add hacked proof-of-concept for "Missing content" message flash fix.

[dillonkearns]

This is an experiment to explore one strategy for addressing #42.

You can view this page to see the current prototype of SSR in elm-pages: https://5e226204a2ae6a0008328c65--elm-pages.netlify.com/blog/introducing-elm-pages/

Note this doesn't technically do server-side rendering (SSR). Instead, it does the following:

• Pre-render the view on the server
• Once the pre-rendered view is rendered in the browser, the Elm app is initialized and then replaces the pre-rendered DOM

This can give similar benefits, but it's not exactly the same.

In terms of having a page that can be crawled by search engines without running JavaScript, and other similar SEO benefits, it's just as good. Some experimentation and measurements still need to be done to understand what kinds of issues there may be when the pre-rendered DOM is replaced by the client-rendered DOM.

Issues with this approach, known and unknown (testing, measurements, and observations are very welcome!)

• What happens with CSS animations when the DOM takes over?
• When an <img> is overwritten in the DOM, it seems like it has a quick flash because of VirtualDom_virtualize causes flashes on <img> elm/virtual-dom#144

Benefits that real SSR could provide

Current features

• Doesn't call the user's update function during the pre-rendering stage. Instead, it just calls init so you will have control over what is presented in the pre-rendered view (and it is deterministic, rather than calling update a variable number of times depending on how long pre-rendering takes).

Possible experiments to try

• Consider using requestAnimationFrame. Here's an Ellie illustrating a pre-rendered view being taken over with an Elm app that's initialized: https://ellie-app.com/m27khddMDya1. Also notice that the Ellie renders it off in a hidden view and the replaces the pre-rendered view when it's done.

[dillonkearns]

This was implemented with #48.