Because it looks like virtual-dom is very well suited for how hplayground works. It's very efficient in rerendering the DOM tree when you have local changes. It's also very fast, seehttp://elm-lang.org/blog/Blazing-Fast-Html.elm
Purescipt because it has a lot of speed in development (libraries) and generates in general leaner javascript. But I have no particular objections against Haste :-)
On Wednesday, 13 August 2014 11:55:04 UTC+2, Alberto G. Corona wrote:
2014-08-13 11:05 GMT+02:00 Rik van der Kleij
<rikvd...@gmail.com>:
Maybe you should port hplayground to purescript and virtual-dom :-)
why? for some special reason?
On Wednesday, 13 August 2014 00:13:42 UTC+2, Alberto G. Corona wrote:
I did the todo application, (see
todomvc.com) to check if the concept was expressive and robust enough to do it:
I think that the model works and the haste compiler works very well too. I don´t know any serious limitation. "wcallback" generates spurious DOM elements and so on, but that can be fixed.
2014-08-12 23:42 GMT+02:00 Wojtek Narczyński
<woj...@power.com.pl>:
On 12.08.2014 23:27, Alberto G. Corona wrote:
Well, it is not a hack. It is the way hplayground works . normally it rewrite the HTML DOM of the implicit divs that are below the event source. "at" permits to assign freely that location.
3. Are you yourself aware of any serious limitations of your approach?
--
Wojtek
--
Alberto.
--
Alberto.