Live data from Hacker News

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

yesodweb.com

41–50 of 113 posts

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

#41
post #5

Earlier quoted context omitted.

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 boundar…

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.

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

#42
post #28

Earlier quoted context omitted.

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

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

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

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

#43

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 funct…

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

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

#44
post #9

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?

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

#45
post #38
post #26

Earlier quoted context omitted.

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, wh…

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

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

#46

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 t…

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.

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

#47
post #9

Earlier quoted context omitted.

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

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

#48
post #45
post #38

Earlier quoted context omitted.

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, wh…

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

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

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

#49

Earlier quoted context omitted.

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.

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

#50

Earlier quoted context omitted.

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

Post reply on HN