Getting offtopic here, but what would you say is the difference between snap and happstack? I ignored happstack for the longest time because of the association with what is now acid-state. When snap came along I checked it out, and then more recently I looked at happstack and got a "so, it's pretty much the same as snap?" feel. Is snap just a better marketed happstack? What would your sales pitch for happstack be to a snap user?
I think you mean, "Snap is pretty much the same as Happstack", since Happstack came first, and Snap borrowed many ideas from it.
I would tell Snap users they should use Happstack because we have a shiny 3D graphic on our homepage. That is based on my in-depth research which indicates that many people decided to use Snap because it had the prettiest homepage. :)
I didn't mean to imply happstack copied snap, but rather that my perception of happstack as "weird" was wrong and it is actually pretty much the same. The sales pitch request wasn't hypothetical, we've only been using snap for a little while and I actually am interested in any advantages happstack may offer.
Well, there is no bad choice when it comes to picking a Haskell web framework. They are more alike than they are different. Anything you could develop in one, you could develop in another. There are certainly no magic bullets in any of the frameworks.
There are certainly many minor design decisions that you can compare. For example, last time I looked at Snap, it seemed like variables captured from the url, got mixed into the same environment as key/value pairs from the QUERY_STRING and POST data. And, they explicitly decided to provide only a Snap monad, but not a SnapT monad transformer. But, none of those are, in themselves, things that warrant switching.
You could also consider which technologies the frameworks embrace, such as Heist vs HSX. At the same time, heist is officially supported by happstack (and even documented in the crash course). A lot of the core technology like acid-state, heist, hsx, jmacro, persistent, etc, can be used with any of the frameworks.
It mostly comes down to picking the framework that is investing the future you think is most exciting.
So, if the Happstack Philosophy and Roadmap get you excited, then use Happstack. If you think Snap's vision of tomorrow is more exciting -- then use Snap.
> Last time I looked at Snap, it seemed like variables captured from the url, got mixed into the same environment as key/value pairs from the QUERY_STRING and POST data.
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) 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...), 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) 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.
