I wouldn't call Yesod "anti-haskell". By default, it relies on QuasiQuotes and TemplateHaskell a lot [1], which are extensions to the GHC. So by default, you'd have a hard time running Yesod applications on anything else but GHC (the Glasgow Haskell Compiler). These extensions allow you to write in an EDSL that generates Haskell for you. IMO, Yesod's use of these extensions are a benefit, as it allows the user to get stuff like type-safe URLs in HTML for free (e.g. you put href=@{Home} on your HTML element and Yesod will ensure that the value interpolates to a route that exists at compile time).

Haskell libraries often depend on language extensions, whether it is overloaded strings or type families or whatnot... so I think it's strange that Yesod gets picked on for doing the same: taking advantage of the tools provided by GHC to create a better environment for the developer.

[1] http://www.yesodweb.com/book/haskell#template-haskell-14

I'm guessing, but I think it's because yesod uses a lot of magic such as templates and the like. The other frameworks like Snap use more idiomatic Haskell.

Yesod is designed to try to replicate rails style frameworks, which as an approach, doesn't work well in a static language. It is also designed to try to hide any traces of haskell. Rather than provide a framework to write haskell code in, they use quasi-quotation to provide a bunch of totally different syntaxes for different parts of the app, which get compiled to haskell behind the scenes. Most haskell users prefer to write haskell rather than specialized, single use languages with limited functionality and poor error reporting.

Then on top of that, the marketing behind yesod is essentially deliberate mis-truths that suggest weaknesses in haskell which do not exist. See how pilgrim689 thinks that the EDSL yesod uses for routing "gets you type safe urls"? Type safe urls are also available in happstack and snap, but written in haskell rather than a weird custom pre-processor language. The EDSL is just giving you a different syntax (and making error messages complex and hard to understand), not giving you the type safety. Pointing out that creating custom languages that are inferior to haskell and have no benefits is bad results in whining of "stop picking on yesod just because we use extensions, everyone uses extensions!", despite the use of extensions never being brought up.

As for more information about web frameworks in haskell: I've tried all three and can give you my thoughts. I ended up using snap, so consider me biased when reading this. Yesod is rails-like in that it pushes a misinterpretation of MVC on you that encourages writing redundant code. Happstack and snap aren't really frameworks in that sense, they don't say "give me some code following my conventions and I'll run it", they say "here's how you get access to the request, have fun". More like libraries than frameworks.

Yesod's DB access layer they provide is of the "dumb everything down to the lowest common denominator" variety, except that it adds even more limitations beyond that. So you end up having to use something else that is not integrated at all. Happstack and snap don't provide a DB access layer, but do provide integration with several DB libraries off hackage (hdbc, haskelldb, postgresql-simple, acid-state).

Happstack has the best documentation of them, and it and snap are very similar design wise. Porting an application from one to the other is pretty straight forward. The only reason we settled on snap instead of happstack is that snap includes a development mode that works well, and happstack does not. Meaning with snap you just change your code and it picks up the changes, recompiles and reloads it automatically, and shows you any errors in the browser when you refresh. With happstack you either need to work out your own way to deal with that, or keep recompiling manually all the time.