Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

This isn't reddit, please spare us the memes and +1s. I think the odds of such a contribution being well received are quite low given the hostility to that notion the developers of yesod still display. Given that I can't see any benefit to using yesod, it seems like a waste of time for me to contribute an unwanted template engine to it.

Sorry for being unclear as well: I meant the initial reply by gregwebs but didn't want to start a second comment.

Thanks for the rest of your answers.

It is absurd, and saying "I only look at people who like hamlet, and all I see is people who like hamlet" doesn't make it any less absurd.

>Your comment about Yesod having nothing unique shows you never really used Yesod or are very intentionally trolling

Again, stop with the accusations and consider the very real possibility that not everyone shares your preferences.

>For example, Snap does not have type-safe urls and Happstack has a very different approach to its related routing

Except that I can use web-routes with either, and end up with the same thing. How exactly does "yesod does a trivial thing like routing slightly differently from the default way snap/happstack do it" become some compelling unique feature? How easy is it to not use yesod's routes?

I would actually appreciate if you could list some other examples. We use postgresql, so nothing persistent related was of interest to us. If we don't like the templates, that leaves form handling and some trivial stuff like sessions, routing, etc. Sessions are effectively the same across all three, routing is more flexible in snap/happstack than yesod, and yesod's form handling appears to be "like digestive-functors but dependant on persistent". If you think yesod is a good choice for someone who won't be using persistent or hamlet, then I am genuinely interested in hearing the reasoning.

- Someone who hijacks a request with the cookie in it cannot see the data in the cookie. But they can access the site as the user, so there is no real world benefit to this fact. - Someone on the same computer cannot see the data in the cookie. But again, they have the cookie value, so they can access the site as the user, so there is again no real world benefit to the fact that they can't see the data in the cookie itself, because they can interact with the site and see the data there.

I guess I'm just looking for an example scenario where the cookie being encrypted offers a concrete benefit from a security standpoint.

(2) If someone has your cookie, they're either already on your connection or they're on your computer.

(3) The only situation where this provides any security is one in which you store data in the cookie that would not be accessible to the same user through the site. I can't think of any such data in any of my experience, but I will absolutely grant that such data may exist.

  http://www.yesodweb.com/blog/2012/04/working-together

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 :)