Hacker Newsnew | comments | show | ask | jobs | submit login
Yesod 1.0 - a robust, friendly, high performance web framework for Haskell (yesodweb.com)
145 points by dons 1111 days ago | 109 comments



I have one question about yesod: how easy is it to switch templating languages? I had a look at it more than once, but hamlet always turned me off. Is it easy to switch to, say, hastache?

-----


I don't think anyone's actually done it, because most of our users really like Hamlet. That said, switching should be a piece of cake. All you need to do is get the textual result from the templating language you're using and apply preEscapedText to it. Since we use blaze-html under the surface, any templating languages using that library's types will automatically work with Yesod.

Of course, support for type-safe URLs will vary by templating languages, so you may have to manually render URLs yourself, but that's doable via getUrlRender.

-----


hamlet is by far Yesod's best feature. I have already ported it to Ruby (hamlet.rb) and Javascript (hamlet.js).

Many users come with different pre-conceptions about what a good template language should be, but once they actually start using Hamlet, they love it. So honestly I am not 100% sure how much effort using a different template language is because not a single user has wanted to switch to an alternative.

That said, give us your use case on the mail list (after giving hamlet a shot) and we will figure out how to make it easy for you. Also, we have users using mustache client side after first generating their mustache templates with hamlet.

-----


My problem with Hamlet is that using it would cause a lot of unneeded pains and errors. I have a team of consultants doing all HTML coding, and they've been doing HTML for years (and are thus accustomed to writing pure HTML). If they just happen to close a single tag anywhere in any page, the application crashes.

If that is robust, then I'm not sure what definition you are using.

-----


I'm not sure where you get that info. You certainly can close tags in hamlet. (I often do). You just do not have to.

-----


I'm getting the info from testing. I tried using Yesod for a while but kept getting this error:

    "A tag name may not contain a slash. Perhaps you have a closing tag in your HTML."
Which you can find in the source for the parser as well:

    if '/' `elem` tn
          then fail "A tag name may not contain a slash. Perhaps you have a closing tag in your HTML."
Maybe there's a way to work around this so you can use closed tags, but it sure wasn't obvious.

-----


I agree. Having also used erb and haml, I find that Hamlet is the best of both worlds. close enough to HTML for designers to understand implicitly but with a lot of the HTML warts gone.

-----


I noticed that hamlet.rb is based on slim. Why not use slim directly?

-----


>hamlet is by far Yesod's best feature

In your opinion.

>but once they actually start using Hamlet, they love it ... not a single user has wanted to switch to an alternative.

Hamlet is one of the major reasons we're using snap instead of yesod. Of the 5 devs here who worked on a test app in yesod, the most favourable reaction to hamlet was "well, I guess I could live with it if I had to". Just because we didn't come ask "how hard is it to use a decent template system with yesod" doesn't mean we love hamlet. We just tried out snap and happstack instead, where using whatever template engine you want is obvious and trivial.

-----


I think you may be re-enforcing what I said. You came with a different pre-conception about what templates should be and didn't use Hamlet for a long period of time.

On the other hand, it seems you are very adamant that you must type your own closing tags rather than have the template language ensure they are correct through indentation.

Our goal is not to make every single developer happy. If you don't appreciate DRY & reduced errors (improper closing tags in this case), Yesod is certainly not for you, no matter what template language you used.

-----


I am not re-enforcing your statement at all. I think it is absurd to suggest that people will just suddenly start liking hamlet if they put up with it long enough. I used PHP for over a decade, I still think it is an awful template engine. Hamlet has the same problems as PHP, and added a new one. And the main part of your post I was objecting to was "everyone loves it and nobody has ever wanted to use anything else". We wanted to use something else, but once we stop using hamlet, there's nothing left making yesod unique vs happstack and snap, so we just switched instead of complaining.

-----


Its not absurd, that has been our experience the majority of the time.

Your comment about Yesod having nothing unique shows you never really used Yesod or are very intentionally trolling. For example, Snap does not have type-safe urls and Happstack has a very different approach to its related routing. I could come up with a lot of other examples.

-----


>Its not absurd, that has been our experience the majority of the time.

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.

-----


You say you can use type-safe urls, but you aren't actually doing it. And the reason why is it isn't supported end-to-end by your framework. You can't stick one in a Heist template, and your routing code would become more tedious because routing is not completely trivial.

But Again, this is just one example.

In your case I doubt any benefits you would receive from switching to Yesod would overcome your switching costs. I would love to have a reasonable discussion about it. But you chose to give us zero feedback until we make a 1.0 release announcement (which means we are going to now limit our changes) and then come out of the wood-work and pic at every nit you can find in the comments of the release announcement and state some other framework is better. Stopping by #yesod to discuss, criticizing on the mail list, or helping your own favorite framework reach 1.0 would be a lot more productive.

Edit (because I can't reply): Thanks for bringing up issues on IRC. If you ask on the mail list you are guaranteed a thoughtful answer. We push users towards Hamlet in part because of the type-safe url support, but you are definitely welcome to use any template language you want.

-----


geek-slapping the troll :) +1

[EDIT]: should not have posted this.

-----


>You say you can use type-safe urls, but you aren't actually doing it

I'm not because I don't want them. If I did I would be using blaze-html and web-routes.

>But Again, this is just one example.

I politely and genuinely asked that you provide those other examples, as the one you did provide is obviously bogus.

>But you chose to give us zero feedback until we make a 1.0 release announcement

Actually, I did ask in IRC about a year ago. And two days after I asked you offered up the same response you have been giving here: "hamlet is perfect and you are wrong for not liking it". I also got similarly slow and unhelpful responses with other issues, like how yesod used to only work on ipv6.

>and then come out of the wood-work and pic at every nit you can find in the comments of the release announcement and state some other framework is better

If you were a little less defensive and a little more reasonable, you might see that I never said anything of the sort.

-----


What were the problems you saw in Hamlet?

-----


First of all, working on a framework (Padrino) myself: I firmly believe that "there's nothing better then ours" without actually answering the question properly is a rude thing to tell someone who asks for replacing a part. So, is there a system in place that allows me to use any templating language that conforms to a given protocol? And where can I find that protocol? (in Padrino, for example, this is Tilt)

Okay, whats wrong with hamlet. It begins on google: "yesod hamlet" does not yield any meaningful documentation. "Shakespearean Templates" does. So "Shakespearean Templates"[1] is a whole family of languages that solves a lot of problems already solved, but type-safe. Well... okay, so I do not only have to learn a whole new framework, I also have to learn 3 new languages (-2, if I only care about HTML templating). So, to me, the whole approach rings a bit of "the world is wrong and we fix everything". Considering gregwebs answer: even more so.

Hamlet just doesn't suit my tastes. I don't like auto-closing tags on intendation - any decent text editor should assist you enough to do that properly. I like how you put thought into generating URLs, but thats nothing the templating language should take care of. Also, Hamlet assumes that you are templating HTML - I often template other types as well, for example plain text - hence a need for replacing it by something that fits all needs better. In the end, I also prefer strictly logic-less templates, so hamlet doesn't cut it.

Also, the documentation should see some love. There is no way to have a look at the features (and languages) in isolation: Its a stream of consciousness that introduces features in a half-sentence (I had to grep it to find what "^" means - it was what I expected it to be, but nevertheless).

That said, I still find Yesod a compelling framework and it will be the first haskell framework I'll try out next time I have some spare time. But the first thing I'll do is replace the templating.

[1]: I would prefer if they had anything to do with shakespeare, the esoteric programming language. ;)

-----


> I firmly believe that "there's nothing better then ours" without actually answering the question properly is a rude thing to tell someone who asks for replacing a part

Sorry for being unclear, I asked because I am genuinely curious and I think all the yesod people love hearing feedback. If you check the yesodweb google group, you'll see that Greg and Michael are constantly begging for and responding to constructive feedback.

> Okay, whats wrong with hamlet. It begins on google: "yesod hamlet" does not yield any meaningful documentation.

Yes, documentation sucks, they're working on it.

> I like how you put thought into generating URLs, but thats nothing the templating language should take care of.

All the template does is provide some syntactic sugar with the @{...} notation. The actual URL generation is handled by the dispatch module entirely.

As for templating, shakespeare-text will do plain text, compile time templates. In general, as Greg has said, you can use anything you want.

-----


> Sorry for being unclear, I asked because I am genuinely curious and I think all the yesod people love hearing feedback. If you check the yesodweb google group, you'll see that Greg and Michael are constantly begging for and responding to constructive feedback.

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.

-----


Personally, I can't stand the "lets mix code and markup" style of template systems in general, which includes most templates. I also hated the indentation system, it just doesn't work well in markup heavy templating. I'm fine with indentation in programming (obviously given that we're talking about haskell), but it drove me nuts in templates as I had to indent far too much, it isn't simple blocks of code being indented, it is "indent everything that is inside something else", which is of course everything.

I found it was just as ugly and awkward as JSP/ASP/PHP, but with the added detriment of forcing me to use indentation where I didn't want it to make it look even less clear, and no closing tags so existing tools look at it and puke. I actually like syntax highlighting. I am atypical I think in that I like zope/lift/heist templates where the template is just pure HTML, and it calls out to "snippets" of code to do anything dynamic. But given the indentation issue, I'd sooner use JSP than hamlet.

-----


> Personally, I can't stand [...] I also hated [...] it drove me nuts [...] I found it was just as ugly [...]

https://www.google.nl/search?&q=haters-gonna-hate&tb...

As explained before in this thread "shakespear-text" is the plain-ERB of Yesod.

To unmix code and markup i'd advise simply use you discipline; it's far to handy to use it sparingly but avoid it otherwise. (But that's my opinion)

I think your contribution of a tag-based template language (like Snap's Heist, or JSP) integration with Yesod will be well received by the Yesod community.

http://hackage.haskell.org/package/shakespeare-text-1.0.0.1

http://www.yesodweb.com/book/shakespearean-templates

-----


http://ycombinator.com/newswelcome.html

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.

-----


> This isn't reddit, please spare us the memes and +1s.

Ok. Yr right, point taken.

> 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.

Hostility I've never encountered. I think the Yesod is super welcoming contribs (the recent discussion on pipes/conduits being a great example of that).

> 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.

Do you mean "can't see any benefit to using yesod" over using Snap? Because I see quite a bunch of benefits in that comparison. Let me name the ones I perceive as benefits:

* More type-safe

* Write less code to get it done (using template haskell and quasiquoting -- in other general terms they are "small DSLs")

* More vibrant community

* Faster (Warp is screaming fast)

* More like Rails (yups this is an advantage to me as I quite liked Rails for some reasons that Yesod seems to copy)

-----


The hostility is on display right here, just asking how hard it is to use another template engine gets you a "hamlet is the best" response from one of the devs.

Your list of benefits is a list of things you like. Telling me what you like doesn't make it so that I also like what you like. Yesod offers no advantages to me, as I would be using it without hamlet and without persistent, making it just an uglier happstack or snap. As I said elsewhere, I am one of the significant number of people who feel yesod's over-use of template haskell and qq is unnecessary and detrimental. It seems to appeal primarily to non-haskellers.

-----


> The hostility is on display right here

7+ hours before you posted this an anwser to Agorak's question "how easy is it to switch templating languages?" was kindly given by Michael Snoyman (lead dev of Yesod).

http://news.ycombinator.com/item?id=3817124

He says: "I don't think anyone's actually done it, because most of our users really like Hamlet. That said, switching should be a piece of cake. All you need to do is [...removed techincal details...]"

I cannot find anything that you describe as hostile.

I think this whole "hostility" thing you seem to perceive is simply not there. Just friendly open source collaboration for the greater good is what I see.

-----


Yes, he posted that after Greg posted "no, hamlet is the best thing ever nobody can want to use anything else". Greg is the other yesod developer/maintainer. Notice other people have replied with similar sentiments. I think your love of yesod is blinding you.

-----


Can anyone please explain me why I got downvoted for asking a question about the linked framework?

-----


I think your question is valid and upvoted you for it.

-----


Congratulations! I have been working with Yesod off and on for about 6 months now. It is truly fantastic; I am actually transitioning off of Django in favor of Yesod. Type safety and conduits for the win.

-----


Some points:

* Generating migrations automatically when saved may cause some troubles while making large changes. It's a default setting?

* Hamlet seems good but not so obvious for real-world designers. Would be great if you provide an easy way of switching to another template language.

* Keep the good work :)

-----


It is a default but its quite simple to turn off. In one project, we turned it off and whipped up some quick shell scripts to do rails style up/down migrations.

-----


Thanks! Actually I am convinced that Hamlet is the best template language for real-world designers because it is just HTML. Our reports back from designers have all been very positive. For Haskell Hamlet (there is a Ruby & JS version) certainly manipulating Haskell code is different that what they are used to, but that has little to do with Hamlet. There is an advantage however: they get an error message right where the error is at compile time rather than having to trace things at runtime.

-----


From the Learn More link at the bottom [1]:

> Note the awesome Shakespearean inspired name convention. Another good reason to use yesod.

Lol.

> Until here I believe it goes in the right direction. Even if I believe the real future is by generating HTML pages from the client (using javascript) and server limited to serve JSON (or XML, or any object representation system).

This is a little unclear. Do you mean, prior to Yesod you thought web development was heading in the right direction, but Yesod made you realize there was a much better way, even if the future is HTML5 rich web apps with the app server as a JSON/XML API endpoint?

1. http://yannesposito.com/Scratch/en/blog/Yesod-excellent-idea...

-----


Mainly, I believe that most the energy put in Yesod goes on the problem I find the most important.

- Security by default, directly imported from the Haskell type system.

- Fast, also, because Haskell is quite fast compared to most languages used for the web.

- Able to manage a lot of concurrent connexions,

- Incredible foundation language, Haskell is simply awesome (look at my latest blog post for details[^1]).

On the other hand, IMHO, the future of the web might be:

- an API server as good as possible (fast/distributed/clever)

- many good quality dynamic (and generally native) clients

Therefore, I find most of the effort put in the HTML/CSS/JS generation while impressive not so essential for what I look. On the other hand, the notion of Yesod's widget is a very clever first step in the direction of web component abstraction. So in conclusion, yes, Yesod went a step further from what I expected from server side web technologies when I discovered it.

[^1]: http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...

-----


Your Haskell tutorial is a very helpful introduction. Thanks! :)

-----


I can't answer with certainty what the author means, but the next set of features planned for Yesod is to have tighter client-side integration. We also agree that's where web app development is headed, but we wanted to start with a solid server-side framework before branching into the client side.

-----


Random question: I believe a while back Yesod did RSA encryption of client-side cookies. Is that still happening?

-----


Yes, the default session storage is in encrypted cookies because it is convenient and good enough for many use cases. The session code is extensible though and someone has already written a Redis backend.

-----


I'm asking because encrypting cookies seems like a pointless exercise, and seemed that way when it was first announced, as well. If you don't encrypt your entire connection, encrypting your cookie seems pointless, no?

-----


The clientsession package (which is what we use) both encrypts and applies a hash to the payload. Hashing prevents users from tampering with the data, and encrypting prevents inspection of the data. This means that you can even store sensitive data in a cookie without worrying if it's being compromised. (Not to say I recommend that practice, but it is possible.)

There is of course some performance overhead to encrypting, but Felipe's skein package has been highly optimized, and Yesod is still able to achieve ~50,000 req/sec on modest hardware. (Apologies for not having more accurate numbers, I haven't run our benchmark suite on EC2 in over a year.)

-----


The content of the cookie isn't compromised, but you can trivially sidejack a cookie on an unencrypted connection and access the information through the website itself, in essence stripping any security. Arguably encrypting the cookie is a waste of processor time, but more importantly I think you may be giving people a false sense of security. The proper way to do secure interactions is via SSL, and I'm not sure encrypted cookies vs simply HMACed cookies gives you any true security advantage (as session storage or anything else).

-----


SSL is (important as you say but) orthogonal to this issue. If you steal a non-encrypted cookie and take over a user's session the result is the same.

-----


Yes, that's precisely what I'm saying. So, let me put it differently: what security advantage does an encrypted session cookie confer? I see two possibilities:

- 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.

-----


I might be wrong here but I think it prevents against a user tampering their own cookie. Say I store User_Id:5 in a cookie and pass it over an ssl connection. The user can still change from User_Id:5 to User_Id:6 and get user 6's account info. Typically you would have to store a non guessable token instead to avoid this. I think by encrypting the cookie you provide the non-guessable part of the equation without having to think about it. This isn't really a benefit from a security standpoint (as in it doesn't provide more security), but it is convenient.

Could be wrong here, I'm not very familiar with Yesod.

-----


the hashing prevents tinkering/tampering

the encryption prevents reading (and thereby also -- to some extend -- but not specifically tinkering/tampering)

-----


As has been said already there is no benefit. It is just a convenient default session storage.

-----


Got it! That makes sense, thanks for following my argument through :)

-----


i can think of only one case: that in which the site owners dont want the user (or sidejacker in case of a non-SSL connection) to see some data they wish to put in the cookie.

i'd cannot think of a web app i worked on where this was needed.

(the hashing is cool though -- tinker prevention is common to be a-good-thing)

-----


Notably, this would only happen if you have data in the user's session that the user themselves cannot get to by using the site. I confess I can't think of any such session data, but I suppose it could exist.

And yes, some sort of HMAC is pretty much mandatory if you're going to do client-side session storage securely, no question.

-----


Encrypting and authenticating cookies allows the web app server (or server farm) to store some session state in the browser rather than hit the database for every little thing. This can have a huge positive effect on scalability.

-----


I'm aware of the benefits of using cookies for session state, just not sure encryption itself offers serious benefits without encrypting the entire browser session via SSL. And it may offer disadvantages from an understanding standpoint, where people think the encrypted cookie provides more security than it actually does.

-----


If properly encrypted with an authenticated encryption mechanism then the server can be sure that the data has not been modified and has not been read. This would allow private data to be stored. As long as the server is the only one that knows the key, then only the server can read it. An evesdropper can still use the cookies for replay attacks, but at that point they're on the connection already.

It's useful for things like storing the current user session. You wouldn't want someone to be able to log in and then change their account to someone else's by modifying the user id in their cookie. Thus this information is often stored in a server-side session. With an encrypted cookie you can push this data to the client, which makes the server stateless with respect to client sessions.

-----


(1) Modification-prevention (the changing your account to someone else's by modifying the user id situation) is provided by the HMAC, not encryption. This is why Rails session cookies are not encrypted (as far as I know), for example.

(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.

-----


(1) Well, he said

> If properly encrypted with an authenticated encryption mechanism

(2) Being on one's connection is the default assumption of the internet security model.

(3) Right, the confidentiality of the site's data from the site's user may not be critical. But if done properly it does allow the site to ensure that the data it stored has not been tampered with (except perhaps to drop it or replay it). Surely this can be useful.

-----


A question I'd love to see a good answer to. We've got Yesod, we've got Happstack, and also Snap.

What are the major differences between them? Is one of them a clear winner, the way Django/Rails are in Python/Ruby respectively?

-----


FWIW, since I only really have experience with Snap: When comparing to Ruby frameworks, you could roughly say that Snap is to Yesod what Sinatra is to Rails.

Snap is relatively simple and as such easy to fully understand. But since it is a relatively simple framework, you have to mix and match other packages to get the functionality that you want.

Yesod on the other hand is very elaborate - it contains a lot of functionality and relies fairly heavily on the use of Template Haskell and Quasi-Quoting.

As with Ruby and Sinatra, it is mostly a matter of taste. Some people prefer lightweight frameworks and add the components they need, while others like to do things within one well-integrated framework.

-----


I think of Scotty as the Sinatra for Haskell: https://github.com/xich/scotty

-----


> FWIW, since I only really have experience with Snap: When comparing to Ruby frameworks, you could roughly say that Snap is to Yesod what Sinatra is to Rails.

I've used both and this is pretty from my experience.

If I can make comparisons I think:

* Yesod is like Rails w/ haml+sass (but type-safety throughout)

* Snap is like Servlets+JSP (especially wrt templating, besides that it is quite similar to Yesod)

* Happstack is like Zope w/o the frontend (mainly because it is the oldest (has a pre-Rails feel to it) and has its own in-haskell ACID db (Zope has ZoDB))

> Snap is relatively simple and as such easy to fully understand. But since it is a relatively simple framework, you have to mix and match other packages to get the functionality that you want.

I found it as hard a Yesod to get it up and running. Both suffer from old docs/tutorials/examples, both needed me to climb the daunting haskell learning curve.

> Yesod on the other hand is very elaborate - it contains a lot of functionality and relies fairly heavily on the use of Template Haskell and Quasi-Quoting.

How is that a problem? I say: "Template Haskell and Quasi-Quoting FTW!" DSLs or little interpreters are great in reducing code-size. Reducing code size is great, arguably nr.1, in reducing bugs.

> As with Ruby and Sinatra, it is mostly a matter of taste.

I suspect you mean "Rails and Sinatra".

It is not a matter of taste: Rails and Sinatra both build on the Rack interface and have several options for http servers (mongrel/webrick/thin/etc).

With Yesod and Snap you find they both have their own "Rack". Yesod has "WAI" and an http server "Warp" -- these blow every other option out of the water in terms of speed and seem to have a more clever design.

But it could be just my opinion. (I did remember reading somewhere that the Snap devs envy Yesod's speed and try to make their solution faster which is a good thing)

> Some people prefer lightweight frameworks and add the components they need, while others like to do things within one well-integrated framework.

This is mostly a matter of how you build your app: "from scratch" or "scaffolded". Both Yesod and Snap allow both ways. Scaffolding with Yesod brings you much further along the axis of "well-integratedness" then scaffolding with Snap which is obviously a win those preferring the scaffolding approach.

-----


>Snap is like Servlets+JSP (especially wrt templating, besides that it is quite similar to Yesod)

Snap offers heist as a default template engine. It is nothing like JSP at all, it is a pure html template engine like lift or zope's templates. There is no embedding any sort of logic or code in the template at all.

>How is that a problem? I say: "Template Haskell and Quasi-Quoting FTW!"

Using is fine, it is intended to reduce boilerplate and works well for that purpose. Yesod over-uses it where it is entirely unnecessary. You lose composability and have to learn another language.

-----


> Snap offers heist as a default template engine. It is nothing like JSP at all, it is a pure html template engine like lift or zope's templates. There is no embedding any sort of logic or code in the template at all.

As a reference: also think Zope's templates and Lift are like JSP. But after closer inspection is see your point that JSP allows some in-template arithmetic that other don't.

> Yesod over-uses it where it is entirely unnecessary. You lose composability and have to learn another language.

I think we can safely agree to disagree on this one. :) Small DSL is not another language in my book; "templates" do not need the same kind of composability that "code" benefits so much from. As you say, it reduces "boilerplate and works well for that purpose" -- great!

-----


Are you saying JSP and meaning something else? I can't figure out any way you could think that other than confusion over what JSP is. JSP is where markup and code are mixed together, using a special delimiter to start and end code parts. Just like ASP and PHP and hamlet and virtually all template engines. Lift/heist/zpt are the exceptions to the rule.

-----


I don't think this comparison is accurate at all. I suspect the author has only used Snap and not Yesod. Actually I don't know if there is a single Haskell programmer that has seriously tried all three web frameworks.

-----


Could you please use arguments, rather than fallacies? I already said that I primarily have experience with Snap. But I did research both Snap and Yesod before using Snap.

Or from the horse's mouth:

Snap: "Snap is a simple web development framework for unix systems, written in the Haskell programming language."

Source: http://snapframework.com/

The Yesod book: "The Haskell community is constantly pushing the boundaries finding the cleanest, most efficient solutions for each challenge.

The downside of such a powerful ecosystem is the complexity of choice. By using Yesod, you will already have most of the tools chosen for you, and you can be guaranteed they work together."

Source: http://www.yesodweb.com/

-----


I am very surprised that you think you can make accurate comparisons through googling! But perhaps this points to a documentation problem with Yesod.

I am probably being entirely too harsh here. It is just that when you call something "elaborate" that is not an objective statement taken from the docs. You were probably trying to phrase things in an objective way, but I think every developer views "elaborate" as having a very bad connotation.

I also disagree with the Sinatra vs. Rails comparison for various reasons, but I don't want to spend time arguing analogies.

-----


As someone who loves yesod, this feels kind of accurate, but I don't see it as a bad thing. Yesod is what a type-safe Rails should look like.

-----


Type-safe, pure-functional Rails; or simply Rails in Haskell.

So not OO, and (opinion warning) a lot less "magic". Template Haskell and QuasiQuoting can be seen as "magic", but I dont think so; they are actually very transparent ways of making small DSLs (a common practice in Ruby-land) w/o the "Ruby magic" needed to create them.

-----


As someone who gave up on yesod because it is so railsish and moved to snap, I'd say it is pretty accurate.

-----


> gave up on yesod because it is so railsish

So what exactly do you feel is bad about "railsishness"?

I think Rails brought a lot of sane defaults and best-practices to a web framework.. I'm not surprised to see nearly all web frameworks that came after it borrow from it. See for instance "Play" on Java/Scala -- very new, very Rails.

-----


[deleted]

I'm not sure what code examples would do, you could use the examples on the yesod site. It isn't a case of "yesod can't do X", it was just out of the 5 people who tried it, 4 voted no. You can't "fix" yesod when it isn't broken, and I think trying to cater to my subjective preferences would simply alienate the people who like yesod.

Your characterization of my posts as trolling is both inaccurate and unnecessary. Having a different opinion is not trolling.

-----


Yesod is the clear winner in terms of features, number of users, active development and community, or probably any other of the usual metrics. That alone doesn't mean it is the best. Rails is the winner in Ruby, but I often prefer Sinatra.

-----


You might also be a little biased being a yesod developer and all. For what it is worth, I found both the happstack and snap communities far more helpful. Yesod makes a ton of assumptions, and questioning those assumptions was met with "just start liking what I like".

-----


I am certainly biased, but these are all objective measurements. I am not claiming that the Yesod community is better, just that it is more active. I am sorry you didn't have a good experience. If you can point to specifics of inflexibility that can help us re-think our design.

-----


Can you show numbers? E.g. number/size of deployments, community size in terms of contributors and mailing list subscribers? How many other packages are dependent on the frameworks? (E.g. Hakyll uses Snap, gitit uses happstack).

Those are objective measures, but without measurements they say nothing.

-----


I subscribe to Happstack's mail list. It has < 1 message/day on their mail list.

Looking at the Snap framework google group there were 7 threads in March and 1 in April. Yesod has had ~15 threads in April and seems to have averaged ~2 threads/day in March.

I am busy at the moment. Perhaps you can help answer your own questions and add to this.

-----


How did you measure the number of yesod, snap and happstack users? "Objective measurement" means something. Keep in mind, "there's more traffic on mailing list X" doesn't mean there's more users of software X, it means there's more users asking questions about it. Given that yesod is much larger, it doesn't seem terribly unreasonable for there to be more questions about using it.

I think you've been displaying the inflexibility I refer to right here. "Everyone loves hamlet because I said so, if you don't love it you don't exist because I said everyone loves it". I understand you like the tools and methods you use, but your reaction to other people preferring other things appears hostile and/or dismissive. Accepting that people can like a different template engine without being objectively wrong might lead to yesod users having a plurality of template engines to choose from.

-----


I concur. The comments from Greg on this article are rife with exactly what you're describing. I have avoided Yesod so far because something about the way the Yesod developers conduct themselves rubs me the wrong way. Now I know what it is.

-----


Michael Snoyman seems to have responded to the whole situation in this blog post:

  http://www.yesodweb.com/blog/2012/04/working-together
I have to say he has increased my respect for him immensely with this.

-----


at this point measuring users or user bases is impossible.

i argue it is also useless.

compared to Servlets+JSP/Rails/Django all of Haskell's web frameworks are smaller-then-tiny.

but: functional programming is on the rise, haskell has become fast and robust, haskell's static typing is seen as an advantage... people want to use haskell for web programming; so haskell web frameworks are seeing growth.

to me Yesod seems to have the edge currently: it is most actively developed and discussed.

i used snap, and liked it, but having tried both i feel yesod makes more sense (maybe because i'm coming from rails).

-----


It isn't yet much of a comparison, but http://www.haskell.org/haskellwiki/Web/Comparison_of_Happsta... has a some info; probably the only thing unique to that page is a list of some sites using each.

I'm using Yesod now simply because it seemed to have the most active community and I don't mind a lot of choices being made for me, since I'm also learning Haskell at the same time. Maybe I'll feel differently later.

-----


If you prefer Django to Pyramid, you'll probably prefer Yesod to Happstack for basically the same reasons. Snap is more like the Java Servlet API.

-----


I would say that Snap is more like Pyramid and Happstack... not quite like anything else. Snap has snaplets, Pyramid has components.

Happstack on the other hand ... invented type-safe routing, which I haven't seen anywhere else before it. Dynamic languages tend to have something vaguely similar you might call "named routes" but they don't provide the same static guarantees.

Happstack likes to use templates mixed in with code, which sounds insane but note that this is rather different from code mixed in with templates. This templating is type-safe and syntactically checked at compile time, and allows reusing all of Haskell rather than a limited subset, so using modules and functions these templates easily end up more modular and composable than any template language you've ever seen before. Admittedly, it's not the most designer-friendly solution (but should designers really mess with the HTML to begin with?).

Happstack likes to use a persistence system for native Haskell values. I suppose you could say this is similar to ZODB with Pyramid, although it's "on steroids" (due to Haskell).

I'm biased towards Happstack as you might notice from this post, but the point I'm trying to make is more that Happstack is non-traditional (in the tradition of Haskell!) and not quite like anything else. This is often seen as a weakness because it means it is less familiar to new users; I might wonder why they're using Haskell to begin with, then. :-)

(You could even argue that Happstack should be more familiar, to Haskell programmers, because it favors reuse of existing Haskell idioms like combinators, algebraic data types, monad transformer stacks...)

That said, if you do want a more traditional framework, Snap and Yesod are both great options.

-----


Believe it or not, Happstack is the one I favor and use, for basically all of these reasons (though I am far too much of a RDBMS partisan to use acid-state).

-----


There's no "clear winner", there are pretty wildly differing opinions on the right approach to things. Yesod puts the most effort into marketing, and seems to pull in the most non-haskellers. The haskell community is kind of split on it, the rampant and unnecessary use of template haskell and quasi-quotation is frowned upon by many, and portions of yesod aren't composable as a result of their DSL obsession.

Yesod gives you templating and persistence out of the box, but the template engine is a love it or hate it deal, and persistent isn't mature enough to use with an RDBMS backend.

Snap gives you templating, but no persistence out of the box. The template engine doesn't give you compile time type safety, but it also contains no logic, it is an html template system like lift. If you want to talk to a database, you use whatever haskell module you want, there's nothing snap-specific about it.

Happstack is basically the same deal as snap, but early on was pretty heavily focused on their own acid-state storage system. It has since become much more storage agnostic, and the acid-state storage system is used outside of happstack now.

Between happstack and snap, happstack has better docs, including tutorials on how to integrate with a ton of different web related modules (different template systems, digestive-functors, etc). Snap has a better web server underlying it, and subjectively appears to have more developers actively working on it. Because both allow you to use whatever modules you like quite easily, migrating an app from one framework to the other is pretty easy. Migrating from snap or happstack to yesod or the other way is quite a lot more effort.

-----


> Yesod puts the most effort into marketing

How is this the case? Compare http://yesodweb.com and http://snapframework.com/ and tell me you really believe that the yesod guys are marketers?

> persistent isn't mature enough to use with an RDBMS backend.

How so? Also, Persistent is still at 0.9, so the version number would agree. Any persistence layer you use with Snap or Happstack is just as easy to use in Yesod too.

> Snap has a better web server underlying it

Again, how so?

-----


>you really believe that the yesod guys are marketers?

I didn't say yesod had the best website, I said they put the most effort into marketing. Michael and Greg do a lot of talking about yesod, and are the only haskell framework attempting to draw in people from outside of haskell. You seem to have interpreted this as an insult, it was not. Usage increases with awareness.

>How so?

Unless you are using your RDBMS like a dumb storage system, then persistent doesn't provide the tools to access it. We're not talking advanced stuff here, the most basic fundamentals were done incorrectly: it requires int primary keys on all tables for crying out loud. Obviously multi-column foreign keys just went out the window then too. Of all our apps here, not even the most trivial could be ported to yesod using persistent.

>Any persistence layer you use with Snap or Happstack is just as easy to use in Yesod too.

Certainly. But the major difference between yesod and snap initially appears to be "yesod provides high level DB access and snap doesn't". This may be true of mongo DB (I have no use for it), but for an RDBMS it actually ends up being that neither provides high level DB access, and you have to use something from hackage.

>Again, how so?

Happstack's webserver has several issues, space usage being a major one. This isn't a controversial statement, Jeremy will tell you the same thing, it is why he's focusing on replacing happstack-server.

-----


>> you really believe that the yesod guys are marketers?

> I didn't say yesod had the best website, I said they put the most effort into marketing. Michael and Greg do a lot of talking about yesod, and are the only haskell framework attempting to draw in people from outside of haskell. You seem to have interpreted this as an insult, it was not. Usage increases with awareness.

There was a heavy implication that they market at the expense of engineer.

> Unless you are using your RDBMS like a dumb storage system, then persistent doesn't provide the tools to access it. We're not talking advanced stuff here, the most basic fundamentals were done incorrectly: it requires int primary keys on all tables for crying out loud. Obviously multi-column foreign keys just went out the window then too. Of all our apps here, not even the most trivial could be ported to yesod using persistent.

Fair enough. We try to stick to the "dumb storage system" model because it gives us a lot of flexibility and makes scaling easier. If you're integrating an existing DB, yeah, it sucks. If starting from scratch, its pretty awesome. But remember, Persistent != Yesod. You'll notice yesod-core doesn't depend on persistent at all.

> Certainly. But the major difference between yesod and snap initially appears to be "yesod provides high level DB access and snap doesn't". This may be true of mongo DB (I have no use for it), but for an RDBMS it actually ends up being that neither provides high level DB access, and you have to use something from hackage.

[[citation needed]] I think the principle difference is that Yesod plays to Haskell's strengths in being "radically typesafe". The amount of errors we see in compiled Yesod code is shockingly minimal.

-----


>There was a heavy implication that they market at the expense of engineer.

I am impressed at your ability to read that which I did not write. There was no such implication, it is a criticism of happstack and snap. More talking = more users = more feedback = better framework. It is especially unfortunate that snap originally seemed to be making serious efforts at marketing, and then just sort of stopped.

>Fair enough. We try to stick to the "dumb storage system" model because it gives us a lot of flexibility and makes scaling easier

We avoid the dumb storage model because it eliminates flexibility, and forces us to re-implement database functionality in our app code. We're talking about starting from scratch, I just don't want to start by throwing away all the power of our database for nothing. Our biggest apps are only in the 10s of millions of rows range, so scaling isn't a problem. If it were, I'd be looking into actual dumb storage systems though (mongo, cassandra, etc) instead of using an RDBMS as a slower version of one.

>But remember, Persistent != Yesod. You'll notice yesod-core doesn't depend on persistent at all.

Yes, but as I said that is the big feature that yesod appears to provide vs happstack and snap. But upon closer inspection we had to go down to hdbc regardless of the framework.

>[[citation needed]] I think the principle difference is that Yesod plays to Haskell's strengths in being "radically typesafe"

Citation for what? That if you don't use persistent then yesod and happstack and snap are similar in functionality? I am not sure how to prove that, how about the other way? What other functionality does yesod offer that I am forgetting?

Yesod avoids haskell in attempting to be "radically typesafe". You get the exact same amount of type safety by using blaze-html and web-routes in happstack or snap as you do using yesod. As I mentioned before, yesod's template haskell, quasi-quotation fetish is rather controversial in haskell land. You can get the benefits yesod offers while retaining composability and the familiarity of using haskell instead learning a DSL. The amount of errors we see in compiled haskell code is minimal, it should not be shocking that this extends to yesod.

-----


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

-----


Great write-up, thanks!

> 2

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.

https://github.com/aslatter/happstack-wai

-----


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.

http://www.happstack.com/C/ViewPage/5 http://www.happstack.com/C/ViewPage/7

- jeremy

(p.s. more meaningful urls are on the TODO list, but it was not critical enough to delay the launch of the new website).

-----


> 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.

This was fixed in the recent 0.8 release.

http://snapframework.com/blog/2012/03/16/snap-0.8-released

-----


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.

-----


They really have to change their website, but in particular that cheesy/glossy logo.

It just looks awful.

-----


We agree, if you click on the home page (http://www.yesodweb.com) you will see a complete redesign. This will be ported to the blog & book soon.

-----


See also:

* http://happstack.com/ * http://snapframework.com/

Design time!

-----


volunteering time! :)

-----


It does. Rails and Node have beautiful sites, but not necessarily beautiful code. Yesod is the other way around.

-----


Doesn't build with the gold linker. Feh.

-----


Based on the commentary, I'll wait for the next high-performance web framework in ocaml. ;)

-----


lol.

-----


hahaha sorry I read the title and could not help but thinking, "a high performance web framework for Haskell" that will not actually output HTML without a doctorate in computer science...

-----


ULTERIOR MOTIVES WARNING:

There is someone under the name "papsosouid" [1] on this thread with an account that's "coincidentally" as old as the thread itself, and has only commented on this thread so far [2].

He seems pretty acquainted to this community (he was quick to show me the HN posting guidelines) therefor I suspect he must have another account at HN. I also suspect he has created this new account especially for posting in this thread: why would one do that? I cano only think of; (a) to conceal whom he really is, or (b) because he expects karma-negative results of his actions -- one not excluding the other.

[1] http://news.ycombinator.com/user?id=papsosouid

[2] http://news.ycombinator.com/threads?id=papsosouid

-----


It isn't a co-incidence, I registered specifically to post in this thread as it is relevant to my interests. I posted the posting guidelines as I just registered, so had just read them myself (they are conveniently linked under the little box you type words in). I am not sure whether I should be flattered or creeped out by your obsession with me, but I'll assume both.

-----




Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: