[Proposal] implement vdom to html

[greyepoxy]

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).
It 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).

With elm 0.16 I used to use vdom-to-html, now with elm implementing its own virtual dom in 0.17 this no longer works.

I wrote a really simple version that would suit my current purposes here. 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.

module definition would be something like
module VirtualDom.ToString exposing (toHtml) ...
Currently this would have to be a native module unless the virtualDom exposes more of its structure in elm.

So here are a couple options,

1. 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 improved dependencies elm-lang/elm-package#168 being solved no easy way to import this into other projects without it being published.
2. 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.

[evancz]

See this status report for some info on this. I expect to add this to the library directly. The code is very simple. The tricky part is figuring out how to expose it such that it is nice to use on a server. In any case, it is basically next on my work queue, so I don't think it makes sense continuing to track it here as this issue will not make it any more or less done.

[greyepoxy]

Cool excited to hear this!

Although your reply does leave me a little confused...
My intent with this issue was to gauge interest and understand that if I did some work on this that it would have some hope of being merged. Turns out I was not the only one intrested, check out this discussion. So why are you doing the work here? From my observations you have thousands of feature requests and probably an endless backlog of things to do with elm. It just seemed like this would have been a straight forward non critical task to let others do...

Second thing that confused me was why close the issue? In every other open source project that I have been a part of or observed issues (for the most part) represent unresolved problems. As of now this is still an unresolved problem that just happens to be near the top of your current priority list. Issues are not just for the maintainers and contributions of a project but also for the users. This approach seems likely to cause confusion because users now have to search both open and closed issues to see if there problem is known. Why not close this issue when you checkin/deploy your solution?

[evancz]

So why are you doing the work here?

The 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 outline those details clearly in a design doc.

The 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) so in the end, there's not a ton of benefit from distribution on this particular project in my opinion.

Not everything is like this of course! There are lots of other projects that folks can help with. Some things are nice for distributed work. Other things are not.

I 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.

why close the issue?

I try to keep issues about bugs in the existing implementation. I do not find "proposal" issues great for getting things done, and they often make it harder to see the actual bugs that are more straight-forward to address.

I may be wrong about that though. I'll open an issue so people can look at what's going on.

[greyepoxy]

Thanks for getting back to me Evan, appreciate you taking the time to clear up my confusion.

The implementation took between 30 and 60 minutes. It is very simple, and it works in the particular way that makes sense for Elm.

Great! Glad to hear it. Looking at https://github.com/elm-lang/virtual-dom/issues/29 it does seem like you are trying to solve more then one problem though. Some unsolicited advice, I would try and break it down into smaller pieces (for example first just do the html to string piece). It appears like you are also trying to solve the problem 'How to host the client Elm on a server.' Which I agree should be investigated/solved but probably not at the same time. In my opinion it would be better to take smaller steps towards the end goal.

Not everything is like this of course! There are lots of other projects that folks can help with. Some things are nice for distributed work. Other things are not.

To be frank I am not looking for a random project (I have plenty of my own). I believe this example is the kind of thing that people are getting at when they say Elm is not very open to the idea of collaborators. I am heavily invested in this particular issue as its a problem that I require to be solved for my own project work. Ideally the best way to get collaborator support is through them helping by solving problems that they are facing in their real work projects. I know that the solutions that get dreamed up are not always the most 'Elm' like, and that is definitely a problem, but one I think could be solved (for example let collaborators host 'unofficial' solutions to problems, maybe through resolving this issue elm-lang/elm-package#168).

I'll open an issue so people can look at what's going on.

Great thanks I think that will be less confusing for people. As an aside not sure I agree with locking the thread down. I know git issues are not ideal and can definitely lead to crazy tangents (for example this conversation...) but they are easy and closer to the code then a lot of other discussion locations.