I agree with you that maybe this proposal is vague for a GSoC, but I don&#39;t think that websockets is a good option either, because not all browsers support them. Indeed, web development has gone a long way without contant communication with the server and I think Haskell should support this way of working too.<div>

<br></div><div>My idea would rather go on the direction of using stablished Haskell concepts to web development. Some ideas are:</div><div>- use an applicative interface like the one of Yesod for forms validation and sending</div>

<div>- see the DOM via a Zipper interface, so widgets will &quot;anchor&quot; themselves in some point of the tree and change things around them</div><div>- use FRP for Canvas interaction</div><div>- ...</div><div><br></div>

<div>Actually, thinking which Haskell concepts could behave well with client-side development is an interesting discussion by its own :)</div><div><br><br><div class="gmail_quote">2012/3/7 Greg Weber <span dir="ltr">&lt;<a href="mailto:greg@gregweber.info">greg@gregweber.info</a>&gt;</span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is obviously a great concept. However, it may not be appropriate<br>
for a GSoC. The design space is far too open, and it is not clear if<br>
anything in that space will end up beating plain old javascript.<br>
<br>
I think my proposal for an awesome websockets library [1] shows that<br>
this is putting the cart before the horse. For some of the potential<br>
javascript solutions, websockets is a dependency anyways. Without<br>
being able to hold open a connection to the server, required server<br>
interaction will be too slow.<br>
Yesod has been successful by explicitly avoiding any new radical<br>
paradigms, but by instead just trying to get the basics of web<br>
development established correctly. Without websockets, we don&#39;t have<br>
the basics down for fluid client-side interaction.<br>
The groundwork for this ticket has been laid: it should be easy to<br>
accomplish with time left over.<br>
So we are guaranteed a clear win for the community. With the time left<br>
over, a solution to the javascript problem can be attempted. But there<br>
is no burden for it to be solved within the summer. Next year the<br>
landscape will be more mature and we can try to come up with a solid<br>
proposal for the javscript problem if the community hasn&#39;t already<br>
created a solution.<br>
<br>
[1] <a href="http://hackage.haskell.org/trac/summer-of-code/ticket/1607" target="_blank">http://hackage.haskell.org/trac/summer-of-code/ticket/1607</a><br>
</blockquote></div><br></div>