I like this direction. One of the things I want in an app is near-instant load time. In addition, this leads nicely toward a server-side Elm "some day" which is another thing I hope for :)
Duane On Thu, Jan 12, 2017 at 10:02 AM, 'Rupert Smith' via Elm Discuss < [email protected]> wrote: > 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. > -- 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.
