[web-devel] Re: ANNOUNCE: yesod 0.2.0

Gour writes:

On Mon, 24 May 2010 17:47:53 +0300

...

...

...

...

...

> "Michael" == 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.ht...) 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.