What do you think of this idea, to provide a 3rd way in which Elm can be set up in the DOM?
We currently have .fullscreen() and .embed(node), a third way would be .attach(node). 'attach' would differ from embed, in that Elm would take over rendering from that node down, rather than insert its rendering output as the first child of the node as 'embed' does. As discussed here: https://groups.google.com/d/msg/elm-discuss/BU6_muFiiVk/hjThLha8AQAJ the reason for doing this would be so that the DOM being attached to, would have some additional attributes or possibly a checksum on it, that would enable the Elm virtual DOM code to re-use a section of the DOM that has already been rendered somewhere else. "Somewhere else" is likely to be a server rendered preview of the content so that the page loads and does its first render as quickly as possible. Such a page is likely to defer loading 3rd party content or initializing more interactive parts of the page until the Elm compiled javascript is loaded, which may take a while. Its a familiar technique from progressive or (dare I say it) isomorphic apps. At the moment if I want to do a quick and approximate render then complete it on the client, I could delete the DOM and have the client completely re-render it. You will see the screen blink; not the end of the world, but somehow not a satisfactory user experience at the same time! Server rendered virtual DOM is possible to do. For example, we know React can do it: https://facebook.github.io/react/docs/react-dom-server.html I have yet to figure out how well this would work with Elms current vdom code. The basic idea seems to be to set a flag or a checksum on the nodes, and use that during the rendering to assesss whether or not a section of the DOM needs to be re-rendered. In the case where it does not, the rendering would still need to walk down the existing DOM and attach event handlers, if the client side rendering adds any. Elm proudly advertises its fast vdom rendering: http://elm-lang.org/blog/blazing-fast-html-round-two Perhaps this extra checksumming and comparison might slow it down? As the extra work would only need to be done when using 'attach' and not the existing 'embed' and 'fullscreen' modes, I anticipate that it should be possible to avoid slowing down existing code by using one vdom implementation or the other depending on the mode. If it is significantly enough slower, perhaps it might not be. I don't think the slow-down will be much, but I'd hate to be the one that bumps Elm down the leaderboard. It also brings up the issue of server side Elm which is not officially supported. Adding this to Elm would kind of imply that it is supported, as that is driver behind adding this feature. Does that need to be considered? I don't need this feature right now, but I may do soon (I'll tollerate the screen blink for now). If folks are generally supportive of this idea, I propose to continue investigating it and write up how to modify the Elm code to do it, also digging into the React code or other implementations. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
