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

[Rik van der Kleij]

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 
> <javascript:>>:
>
>> 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. 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/67874851/attachment.html>