I am Jeremy.. and I am not sure I would tell you the same thing. The Happstack webserver is pretty darn good. Of course, I think we can do even better. In fact, I think we can do better than warp.
Hmm, I'm sorry to have (mis)spoken for you. I assumed you would tell him that since you appear to have been pretty open about it on the mailing list and in IRC. So you think happstack-server is better than snap-server? Or just that I am over-stating the difference?
I know there was talk of switching happstack over to warp, and then more recently of writing another server instead. What is it you are planning to do better than warp, performance, correctness, features or something I'm not thinking of? Is there anything in particular that made you decide not to use warp?
I think that as far as the end user is concerned, there is not much difference between the warp, Snap, and Happstack backends.
Speed-wise, warp is maybe 3 times faster than Snap and Happstack in the pong test. Though, how that plays out in real world is hard to say. But, I doubt anyone is running a Haskell web server right now that needs anywhere close to 30,000+ requests/second. Of course, speed never hurts. Even if you are not doing a lot of requests per second, the totally latency per request counts for something. So, I see no reason for Happstack to be slower than it could be.
Because Happstack is based on lazy IO instead of conduits/enumerators/pipes, there is a perception that it must be leak files and RAM like crazy. But, that is not actually true. The server handles streaming files from disk fine, and even streaming files in POST/PUT to disk in a constant space. We had to be careful inside the server code to make that happen -- but the end user never has to deal with that for the most part.
One exception is when the user wants to use IO to generate a streaming response. For example, if you were wrote an algorithmic music generator that required IO and streaming an never ending MP3. To do that in happstack-server, you could need to use unsafeInterleaveIO. And, be a bit careful.
But, just because lazy IO can work, doesn't mean that something like Pipes would not be better. Happstack predates enumerators/pipes/conduits, so lazy IO was the best choice at the time :) The idea of moving Happstack away from lazy IO has been an the plate for a long time (before Snap and Yesod were even created). Originally we were going to move to the hyena backend. But then Johan went on a major yak shaving expedition and rewrote the GHC I/O manager, etc, instead of finishing hyena.
We did consider switching to warp. But there are a few reasons we decided not to:
1. The source code for warp did not fill me with confidence (yes.. entirely subjective). So, in the new (currently unnamed) happstack-server backend (which will be standalone similar to warp), I want to create a strong body of evidence that it actually works correctly.
2. I like pipes. At least, I like the way they are designed by starting with the core principles and semantics and trying to build something up that is based around solid math foundation like Category. Now, Michael Snoyman may be correct that pipes are not suitable for implementing an http proxy. Once the next pipes (that has resource finalization and exception handling) is out, I intend to discover if that is true or not (acme-http-proxy). (Once again, very subjective).
3. I want Happstack to be a stable platform. Historically, yesod has gone through a lot of radical changes. Something is there one day, and gone the next. My previous experiences trying to collaborate directly and indirectly with the yesod team have left me nervous about building on their work. The yesod project is focused on what is best for their own purposes -- which is fine. But, it means that if you are trying to build on it, you have to be ready to accept whatever may drop out of the sky tomorrow morning. (Also subjective).
4. the yesod dependency hell problem gives me concern as well. While the problems they are experiencing are fundamental to Cabal itself, they seem to be hit a lot harder than Happstack. So, until that is all sorted out, I don't want to make Happstack installs more likely to fail.
Given that warp is less than 1000 lines, it seems like the risks and loss of control involved with trying to leverage it do not really outweigh the cost of implementing a solution that is exactly what we want.
So, I am aiming for better design, performance, and correctness.
In terms of features.. I'm saving that surprise for later :)
Quite some research has been put in from the Yesod team on this matter. Michael Snoyman did not want to release Yesod 1.0 before the matter on pipes/conduits was settled.
> 3
This is because Yesod was not yet 1.0 -- the message was always that after 1.0 API breakage would only be allowed in major version jumps. (as it should)
> 4
Yups, everyone working on several big Haskell projects hopes this can soon be fixed. There's some GSoC proposal for it, I hope it gets through.
One question: would Happstack like to use Yesod's WAI? I see some progress has been made to that goal[1]. If you use WAI then your Warp competitor could also be used for Yesod.
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.
