[web-devel] Re: ANNOUNCE: yesod 0.2.0

[MightyByte]

Gour <gour at ...> writes:

> 
> On Mon, 24 May 2010 17:47:53 +0300
> >>>>>> "Michael" == <michael at ...> wrote:
> 
> Michael> I would say that Yesod and Snap are very orthogonal
> Michael> projects. Without offense to the Snap authors, I don't really
> Michael> think Snap is a framework; it's much more low-level than
> Michael> that. As they put it, it's at the level of a Java servlet
> Michael> container. In that sense, it's slightly higher-level than
> Michael> WAI, but far more low-level than Yesod (or turbinado,
> Michael> happstack, etc).
> 
> I'd agree with that, but they say: "Higher-level facilities for
> building web applications (like user/session management, component
> interfaces, data modeling, etc.) are planned but not yet
> implemented..." and, moreover, they aim at: "Snap aims to be the de
> facto web toolkit for Haskell...  ", so it looks that present release
> is not the end of the story.

Gour is correct here.  We thought long and hard about how to balance the
advantages of "release early and often" with the advantages of not releasing
a half-baked product that turns people away for good.  We decided to err by
being more of the latter.  In fact, Don Stewart expressed some concerns about
our use of that approach.  So we decided to get the low-level parts mature
before release.

Now we're getting these "snap is not a high level framework" opinions, which
almost suggest we should have waited longer.  I don't actually think that, but
you have to wonder.

> 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?

VPSs these days are cheap enough that we decided not to address the
shared-hosting demographic.

> 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.

We'll have to see...

> Michael> * Snap has Heist, which is an XML based templating system,
> Michael> while Yesod uses Hamlet. However, neither framework is
> Michael> actually tied down to these templating systems. In fact, Snap
> Michael> doesn't even depend on Heist.
> 
> Hamlet looks cool to me...
> 
> /me does not like XML stuff...

I don't care for HAML.  I'd rather my templates be in the same general form as
my end-result markup.  Heist makes it trivial to implement extensions to XHTML
ala the pattern used by Facebook for their FBML.  So the approach is not
without precedent.

That said, I believe this is the most common complaint about Snap that I've
seen.  As we've already shown, it's not a valid complaint about snap-core and
snap-server.  But if you don't like XML templates, then Heist is not for you.
To each his own.

> 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).

Awhile back I wrote a blog post about this question.
(http://softwaresimply.blogspot.com/2008/03/to-template-or-not-to-template.html)
My conclusion then was in favor of haskell-generated markup.  This led me to
really want something for type-safe URLs.  I never got around to implementing
something, but I wished for them on many occasions.

After building and running a website on happstack using this approach, I have
changed my mind.  I think that abstracting the generation of a site's markup is
very site-specific, and difficult to get right.  Type-safe URLs are a nice
bonus, but I don't think they're enough to tip the scales.

That said, my only experience with a templated site snapframework.com, so I
still have more to learn.  But so far working with Heist templates has been
quite nice.  I'm planning to do a blog post on this sometime (hopefully near
future).  

So this whole issue is very debatable.  But again, snap-core and snap-server
can be used with either approach.

> 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 don't think this is a significant difference.  Using state instead of reader
hasn't changed Haskell into an impure language.  And you can make readers
behave like a state monad using the local function.