{"action":"created","issue":{"url":"https://api.github.com/repos/elm-lang/virtual-dom/issues/22","repository_url":"https://api.github.com/repos/elm-lang/virtual-dom","labels_url":"https://api.github.com/repos/elm-lang/virtual-dom/issues/22/labels{/name}","comments_url":"https://api.github.com/repos/elm-lang/virtual-dom/issues/22/comments","events_url":"https://api.github.com/repos/elm-lang/virtual-dom/issues/22/events","html_url":"https://github.com/elm-lang/virtual-dom/issues/22","id":157360786,"number":22,"title":"[Proposal] implement vdom to html","user":{"login":"greyepoxy","id":11470527,"avatar_url":"https://avatars.githubusercontent.com/u/11470527?v=3","gravatar_id":"","url":"https://api.github.com/users/greyepoxy","html_url":"https://github.com/greyepoxy","followers_url":"https://api.github.com/users/greyepoxy/followers","following_url":"https://api.github.com/users/greyepoxy/following{/other_user}","gists_url":"https://api.github.com/users/greyepoxy/gists{/gist_id}","starred_url":"https://api.github.com/users/greyepoxy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/greyepoxy/subscriptions","organizations_url":"https://api.github.com/users/greyepoxy/orgs","repos_url":"https://api.github.com/users/greyepoxy/repos","events_url":"https://api.github.com/users/greyepoxy/events{/privacy}","received_events_url":"https://api.github.com/users/greyepoxy/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-05-28T23:07:49Z","updated_at":"2016-07-11T18:14:38Z","closed_at":"2016-07-09T00:40:08Z","body":"So I am one of those people bullishly running elm in node (not super polished but here is an in progress example https://github.com/greyepoxy/elm-GameHostServer).\r\nIt works decently well and allows me to share code between the client and the server. Another cool advantage of doing this is that you can write all of your html in elm (even the page you embed your client program into).\r\n\r\nWith elm 0.16 I used to use [vdom-to-html](https://github.com/nthtran/vdom-to-html), now with elm implementing its own virtual dom in 0.17 this no longer works.\r\n\r\nI wrote a really simple version that would suit my current purposes [here](https://github.com/greyepoxy/elm-GameHostServer/blob/master/src/Native/Http/Response/Write.js). I would like to look into the possibility of writing a more official version but didn't want to just push out a pull request if it has no hope of getting merged.\r\n\r\nmodule definition would be something like\r\n`module VirtualDom.ToString exposing (toHtml) ...`\r\nCurrently this would have to be a native module unless the virtualDom exposes more of its structure in elm.\r\n\r\nSo here are a couple options,\r\n1. Write this functionality in its own project. Not a huge fan since the only way for it to be used would be for it to be published and since it is both a native module for what most of Elm considers an unsupported scenario that is unlikely (at least that is what I have seen in the past). Also without https://github.com/elm-lang/elm-package/issues/168 being solved no easy way to import this into other projects without it being published.\r\n2. Make this part of this project. Advantages would be that we could re-use some of the rendering logic (since it is mostly the same). Tests would ensure that it does not get broken when vdom structure is changed. Disadvantages are I have no desire to completely support isomorphic rendering just yet so the implementation would probably seem incomplete at the moment. What I mean is that ideally when Elm first renders it would attach to the existing dom nodes (if they exist) instead of just re-rendering everything. I am assuming it would be good to avoid experimental functionally in core projects."},"comment":{"url":"https://api.github.com/repos/elm-lang/virtual-dom/issues/comments/231818253","html_url":"https://github.com/elm-lang/virtual-dom/issues/22#issuecomment-231818253","issue_url":"https://api.github.com/repos/elm-lang/virtual-dom/issues/22","id":231818253,"user":{"login":"evancz","id":1658058,"avatar_url":"https://avatars.githubusercontent.com/u/1658058?v=3","gravatar_id":"","url":"https://api.github.com/users/evancz","html_url":"https://github.com/evancz","followers_url":"https://api.github.com/users/evancz/followers","following_url":"https://api.github.com/users/evancz/following{/other_user}","gists_url":"https://api.github.com/users/evancz/gists{/gist_id}","starred_url":"https://api.github.com/users/evancz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/evancz/subscriptions","organizations_url":"https://api.github.com/users/evancz/orgs","repos_url":"https://api.github.com/users/evancz/repos","events_url":"https://api.github.com/users/evancz/events{/privacy}","received_events_url":"https://api.github.com/users/evancz/received_events","type":"User","site_admin":false},"created_at":"2016-07-11T18:14:38Z","updated_at":"2016-07-11T18:14:38Z","body":"> So why are you doing the work here?\r\n\r\nThe implementation took between 30 and 60 minutes. It is very simple, and it works in the particular way that makes sense for Elm. It is probably not more efficient to have such a small amount of work distributed when the implementation details are really the only thing that matter, and it would very likely take longer than 30 minutes to write it up clearly.\r\n\r\nThe actual work is talking to users to see how it fits in their workflow (which I would need to do to vet any public API anyway) and writing the blog post announcing it (which I know I can get wide readership on.\r\n\r\nNot everything is like this of course! There are lots of [other projects](https://github.com/elm-lang/projects/blob/master/README.md) that folks can help with. Some things are nice for distributed work. Other things are not.\r\n\r\nI understand you may not find this satisfying or may disagree with my prioritization choices, but I understand the tradeoffs here and ultimately have to make the executive decision. Maybe it's wrong, but I felt it'd be nice to explain my perspective.\r\n\r\n> why close the issue?\r\n\r\nI try to keep issues about bugs in the existing implementation. I do not find \"proposal\" issues for getting things done, and they often make it harder to see the actual bugs that are more straight-forward to address.\r\n\r\nI may be wrong about that though. I'll open an issue so people can look at what's going on."}}
{"actor":{"display_login":"evancz"}}