Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript. I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution. [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607
I agree with you that maybe this proposal is vague for a GSoC, but I don'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.
My idea would rather go on the direction of using stablished Haskell
concepts to web development. Some ideas are:
- use an applicative interface like the one of Yesod for forms validation
and sending
- see the DOM via a Zipper interface, so widgets will "anchor" themselves
in some point of the tree and change things around them
- use FRP for Canvas interaction
- ...
Actually, thinking which Haskell concepts could behave well with
client-side development is an interesting discussion by its own :)
2012/3/7 Greg Weber
This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript.
I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution.
[1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607
On Wed, Mar 7, 2012 at 11:47 AM, Alejandro Serrano Mena
I agree with you that maybe this proposal is vague for a GSoC, but I don't think that websockets is a good option either, because not all browsers support them.
We already have a websockets library, but like you say it is not very useful by itself because it may not be supported in all browsers. The GSoC proposal is to create a library that will use appropriate fallbacks on all browsers, which is how websockets are normally used.
2012/3/7 Greg Weber
This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript.
I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution.
[1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607
participants (2)
-
Alejandro Serrano Mena -
Greg Weber