[Haskell-cafe] The Good, the Bad and the GUI

[Alberto G. Corona]

Yep, but virtual-dom is more appropriate for declarative reactive
frameworks like elm. It need to know what parts of the DOM must be
refreshed because the whole elm expression is reevaluated when an event
happens. It need to detect the changes. Otherwise, it would have to repaint
the whole screen in each event.

Declarative reactive is like a giant event handler that all the events
execute. It may have some event/signal preprocessing  to mix events/signals
depending on timings by means of some special combinators, but at the end
it executes the whole declarative expression, which includes the
re-generation  of all the rendering.

hplayground execute just the part of the monad corresponding to the branch
in which the event happened. So it does not need to maintain the old and
the new version of the DOM in order to detect the parts to be updated. It
updates the affected branch of the DOM directly. So it must be faster (I
did not check it however).


2014-08-13 12:34 GMT+02:00 Rik van der Kleij <rikvdkleij at gmail.com>:

> 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, see
> http://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... at 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:
>>>>
>>>> https://github.com/agocorona/hplay-todo
>>>>
>>>>  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... at 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.
>>>>>>
>>>>>
>>>>> Okay, I see.
>>>>>
>>>>> 3. Are you yourself aware of any serious limitations of your approach?
>>>>>
>>>>> --
>>>>> Wojtek
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alberto.
>>>>
>>>
>>
>>
>> --
>> Alberto.
>>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/8bc54c1c/attachment.html>