When Greg and I started Snap (Yesod didn't exist then), we did so because we were both running sites on Happstack and felt things could be done better. First,

When Greg and I started Snap (Yesod didn't exist then), we did so because we were both running sites on Happstack and felt things could be done better. First, at the time we had seen Happstack's lazy IO web server choke at high load and we wanted to implement a web server based on left-fold enumerators. This had already been talked about for some time (http://code.google.com/p/happstack/issues/detail?id=29 http://code.google.com/p/happstack/issues/detail?id=29) but as of now still hasn't been done. Second, we felt that the (then woefully undocumented) API was overly complex, exposed too much of the internals to the user, and was difficult to learn. For instance, it exposes two different monad transformers ServerPartT and WebT (http://hackage.haskell.org/packages/archive/happstack-server/7.0.0/doc/html/Happstack-Server-Internal-Monads.html http://hackage.haskell.org/packages/archive/happstack-server...), and back then it was not obvious when to use each one, causing the user to suffer from the paradox of choice. Third, we wanted to have a strong focus on good software design with clean, well-tested code. Departing from happstack was not a decision undertaken lightly--we agonized long and hard. When we released to the public, Snap was the first serious high-performance Haskell web server based on left-fold enumerators to reach a usable level of maturity. We received an extremely positive reception documented both here and on reddit. That was two years ago. Fast forwarding to today, Happstack has made a lot of progress. Jeremy has done a fabulous job with the happstack tutorial. However it's still using the same lazy IO web server and still talking about changing. The API is still mostly the same except that the doc pages have been modularized in way that I find makes it harder to find what I'm looking for. I'd be tempted to say it's an objective criticism, but it could just be personal preference. It also looks like a significant amount of work has gone into web-routes and type-safe routing. This is usually marketed as being a Happstack thing, but as Jeremy recently demonstrated (https://github.com/stepcut/snap-web-routes-demo https://github.com/stepcut/snap-web-routes-demo) it can easily be used in Snap apps. During that time Snap has come a long way as well. We've ironed out a lot of bugs in the web server and associated API. A lot of thought has gone into preventing slowloris attacks, file upload vulnerabilities, and the like. We also have SSL support. Six months after we released Snap, Warp came onto the scene with better raw performance numbers, but it's not obvious to us that sacrificing the Snap web server's maturity for extra speed is in the best thing for our users. On the high-level side, we've made great progress exploring the Heist templating paradigm. It has proven to be very flexible and have gotten a number of comments about how much users love it. You can also use Heist with Happstack, and similarly can use Snap with a different templating system. We spent at least 6-8 months designing our snaplet component system and feel that it turned out very well. Happstack doesn't have anything like this, and a number of the first things you'll likely need in building a web app on Happstack are already available on a modular basis as built-in or third-party snaplets. This is actually the heart of what we wanted to be working on when we started Snap, but we got side-tracked when we realized we weren't going to be able to use Hyena as our web server. In summary, I would say that much of what is stated in the Happstack philosophy is also the Snap philosophy (the little False Simplicity jab at getParam has also been fixed). Moving to the five items in Happstack's roadmap, Snap already has points 2, 3, and 5 as well as some of the items in point #1. Even though it's not evident in Snap, I've always had a soft spot in my heart for acid-state, so I'm eagerly anticipating the planned replication and sharding. Snap already has an acid-state snaplet which means that it's probably easier to use acid-state in a Snap application than it is with Happstack. In my opinion, all this makes a compelling argument for Snap, but I'll echo Jeremy and conclude that if the Happstack project and community get you excited, then use Happstack. If you like what we're doing with Snap, then we'd love to have you using (and hopefully contributing to) Snap. Drop by the #snapframework IRC channel in Freenode. We're usually quite responsive.