[web-devel] Re: ANNOUNCE: yesod 0.2.0

[Michael Snoyman]

On Mon, May 24, 2010 at 6:55 PM, Gour <gour at gour-nitai.com> wrote:

> On Mon, 24 May 2010 17:47:53 +0300
> >>>>>> "Michael" == <michael at snoyman.com> wrote:
>
> [snip]



> Michael> I did some work after the Snap release to actually get Yesod
> Michael> running on top of Snap. Gregory has been very helpful, and
> Michael> will hopefully be releasing a newer version of snap-server
> Michael> that provides the functionality I'm missing. (Basically, Snap
> Michael> processes url-encoded form data, while WAI specifies that the
> Michael> POST body be passed to the application.)
>
> Would it be better option for shared-hosting scenario and FCGI
> serving?
>
> Snap is definitely *not* geared at shared hosting. I discussed this with
Gregory a while ago, and unless he's changed his mind since, they're not
interested in anything but dedicated hosting. So I would definitely say
stick with FastCGI (or CGI... I'm working on some benchmarks right now).


> Michael> * Yesod uses the WAI definition of enumerator while Snap uses
> Michael> the iteratee package. The former is much simpler, the latter
> Michael> more powerful. I'd be very interested in a performance
> Michael> comparison of the two, my instinct tells me the former wins.
>
> I haven't been able to grok either of them...all I can say is that I
> understand this is hot topic in Haskell, and if one wants to dive into
> web development with Haskell, there is need to understand them more
> (hopefully not fully).
>
> Well, Yesod at least shields you from dealing with enumerators, and I
believe most other high-level frameworks will do the same.


> [snip]
>


> Michael> * Yesod has type-safe URLs, I don't believe Snap has any
> Michael> similar feature.
>
> Hmm, this is an important issue and one of the selling tickets to use
> Haskell instead of e.g. Python/Django (which we recently abandoned).
>
> I know that since implementing this feature in Yesod it's completely
changed the way I write web apps. There's no more fear of changing my URL
structure: I just do it, and the compiler tells me if I need to fix
anything. If Yesod goes in the advertising direction, this will most likely
be the top item on the list.


> Michael> * Some design decisions, notably they use a mutable states for
> Michael> modifying request and response values while Yesod uses a
> Michael> Reader for the request, and writer for response headers and
> Michael> actually returns a value for the response body/content type.
>
> What are some of the implications of the above design difference?
>
> I personally prefer the Yesod approach, but of course I'm a biased source.
I found writing code against Snap to be a little... unnatural. For example,
you have to call modifyResponse and give it a function that applies changes
to a response already in existence. It feels very object-oriented to me in
fact.

In Yesod, you can get access to the request via getRequest, and then return
a value that can be converted to a response. The monad plays a much less
important role, and feels overall more functional.

Michael> I'm sure there are many more differences, but the main point
> Michael> is this: these two projects are very different types of
> Michael> frameworks. And I hope and expect that the two projects will
> Michael> have some cross-polinization going forward (in fact, we
> Michael> already have).
>
> Thank you for the input. It looks that it would be nice to make
> another comparison when (hopefully) Snap gets some more higher-level
> stuff and when Yesod will have some solution for persistence
> (hopefully with the ability to use RDBMS).
>
>
> Given my current line of employment, RDBMS is my top priority for the
persistence layer. My thought right now is to start with MySQL, since it has
the weakest Haskell support at the moment. Ideas are percolating, but I
haven't had a chance to actually write something concrete yet.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100524/d1f5b03b/attachment-0001.html