12 ms·

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

145 points by dons 15y ago

yummyfajitas 15y ago
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?
- danieldk 15y ago
  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.
  - gregwebs 15y ago
    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.
    - papsosouid 15y ago
      As someone who gave up on yesod because it is so railsish and moved to snap, I'd say it is pretty accurate.
      - deleted 15y ago
        [deleted]
        papsosouid 15y ago
        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.
      - cies 15y ago
        > 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.
    - maxcan 15y ago
      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.
      - cies 15y ago
        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.
    - danieldk 15y ago
      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/ 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/ http://www.yesodweb.com/
      - gregwebs 15y ago
        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.
  - egonschiele 15y ago
    I think of Scotty as the Sinatra for Haskell: https://github.com/xich/scotty https://github.com/xich/scotty
  - cies 15y ago
    > 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.
    - papsosouid 15y ago
      >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.
- fusiongyro 15y ago
  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.
  - donri 15y ago
    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.
    - fusiongyro 15y ago
      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).
- gregwebs 15y ago
  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.
  - papsosouid 15y ago
    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".
    - gregwebs 15y ago
      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.
      - danieldk 15y ago
        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.
        gregwebs 15y ago
        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.
      - papsosouid 15y ago
- papsosouid 15y ago
  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.
  - maxcan 15y ago
    > Yesod puts the most effort into marketing How is this the case? Compare http://yesodweb.com http://yesodweb.com and http://snapframework.com/ 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?
    - papsosouid 15y ago
      >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.
- mlinksva 15y ago
  It isn't yet much of a comparison, but http://www.haskell.org/haskellwiki/Web/Comparison_of_Happstack%2C_Snap_and_Yesod 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.
miguelos 15y ago
They really have to change their website, but in particular that cheesy/glossy logo. It just looks awful.
- maxcan 15y ago
  It does. Rails and Node have beautiful sites, but not necessarily beautiful code. Yesod is the other way around.
- dons 15y ago
  See also: * http://happstack.com/ http://happstack.com/ * http://snapframework.com/ http://snapframework.com/ Design time!
  - cies 15y ago
    volunteering time! :)
- gregwebs 15y ago
  We agree, if you click on the home page (http://www.yesodweb.com http://www.yesodweb.com) you will see a complete redesign. This will be ported to the blog & book soon.
Argorak 15y ago
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?
- gregwebs 15y ago
  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.
  - maxcan 15y ago
    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.
  - papsosouid 15y ago
    >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.
    - maxcan 15y ago
      What were the problems you saw in Hamlet?
shadowfiend 15y ago
Random question: I believe a while back Yesod did RSA encryption of client-side cookies. Is that still happening?
- gregwebs 15y ago
  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.
  - shadowfiend 15y ago
    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?
    - marshray 15y ago
      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.
      - shadowfiend 15y ago
        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.
        Periodic 15y ago
        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.
caioariede 15y ago
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 :)
- maxcan 15y ago
  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.
- gregwebs 15y ago
  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.
tonetheman 15y ago
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...
NullSet 15y ago
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.
SkyMarshal 15y ago
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-ideas/ http://yannesposito.com/Scratch/en/blog/Yesod-excellent-idea...
- snoyberg 15y ago
  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.
- yogsototh 15y ago
  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/ http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...
  - 15y ago
zoowar 15y ago
Over the weekend I played with happstack, snap, and yesod. Yesod rubbed me the wrong way, I just didn't like the approach they took. Still, of the 3, they have the most compelling set of features making it hard to consider the other 2. For example authentication provides many options, including browserid.
ChristianMarks 15y ago
Based on the commentary, I'll wait for the next high-performance web framework in ocaml. ;)
- cies 15y ago
  lol.
cies 15y ago
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 http://news.ycombinator.com/user?id=papsosouid [2] http://news.ycombinator.com/threads?id=papsosouid http://news.ycombinator.com/threads?id=papsosouid
- papsosouid 15y ago
  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.
- thomasdavis 15y ago
  is this a schizophrenic auto replier?
grout 15y ago
Doesn't build with the gold linker. Feh.

145 points by dons 15y ago

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?

danieldk 15y ago
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.
- gregwebs 15y ago
  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.
  - papsosouid 15y ago
    As someone who gave up on yesod because it is so railsish and moved to snap, I'd say it is pretty accurate.
    - deleted 15y ago
      [deleted]
      - papsosouid 15y ago
        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.
    - cies 15y ago
      > 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.
  - maxcan 15y ago
    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.
    - cies 15y ago
      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.
  - danieldk 15y ago
    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/ 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/ http://www.yesodweb.com/
    - gregwebs 15y ago
      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.
- egonschiele 15y ago
  I think of Scotty as the Sinatra for Haskell: https://github.com/xich/scotty https://github.com/xich/scotty
- cies 15y ago
  > 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.
  - papsosouid 15y ago
    >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.
fusiongyro 15y ago
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.
- donri 15y ago
  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.
  - fusiongyro 15y ago
    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).
gregwebs 15y ago
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.
- papsosouid 15y ago
  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".
  - gregwebs 15y ago
    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.
    - danieldk 15y ago
      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.
      - gregwebs 15y ago
        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.
    - papsosouid 15y ago
papsosouid 15y ago
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.
- maxcan 15y ago
  > Yesod puts the most effort into marketing How is this the case? Compare http://yesodweb.com http://yesodweb.com and http://snapframework.com/ 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?
  - papsosouid 15y ago
    >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.
mlinksva 15y ago
It isn't yet much of a comparison, but http://www.haskell.org/haskellwiki/Web/Comparison_of_Happstack%2C_Snap_and_Yesod 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.

miguelos 15y ago

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

maxcan 15y ago
It does. Rails and Node have beautiful sites, but not necessarily beautiful code. Yesod is the other way around.
dons 15y ago
See also: * http://happstack.com/ http://happstack.com/ * http://snapframework.com/ http://snapframework.com/ Design time!
- cies 15y ago
  volunteering time! :)
gregwebs 15y ago
We agree, if you click on the home page (http://www.yesodweb.com http://www.yesodweb.com) you will see a complete redesign. This will be ported to the blog & book soon.

Argorak 15y ago

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?

gregwebs 15y ago
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.
- maxcan 15y ago
  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.
- papsosouid 15y ago
  >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.
  - maxcan 15y ago
    What were the problems you saw in Hamlet?

shadowfiend 15y ago

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

gregwebs 15y ago
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.
- shadowfiend 15y ago
  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?
  - marshray 15y ago
    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.
    - shadowfiend 15y ago
      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.
      - Periodic 15y ago
        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.

caioariede 15y ago

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

maxcan 15y ago
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.
gregwebs 15y ago
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.

tonetheman 15y ago

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

NullSet 15y ago

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.

SkyMarshal 15y ago

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-ideas/ http://yannesposito.com/Scratch/en/blog/Yesod-excellent-idea...

snoyberg 15y ago
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.
yogsototh 15y ago
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/ http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...
- 15y ago

zoowar 15y ago

Over the weekend I played with happstack, snap, and yesod. Yesod rubbed me the wrong way, I just didn't like the approach they took. Still, of the 3, they have the most compelling set of features making it hard to consider the other 2. For example authentication provides many options, including browserid.

ChristianMarks 15y ago

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

cies 15y ago
lol.

cies 15y ago

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 http://news.ycombinator.com/user?id=papsosouid [2] http://news.ycombinator.com/threads?id=papsosouid http://news.ycombinator.com/threads?id=papsosouid

papsosouid 15y ago
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.
thomasdavis 15y ago
is this a schizophrenic auto replier?

grout 15y ago

Doesn't build with the gold linker. Feh.