
Yesod 1.0 - a robust, friendly, high performance web framework for Haskell  - dons
http://www.yesodweb.com/blog/2012/04/announcing-yesod-1-0
======
Argorak
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
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.

~~~
papsosouid
>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
What were the problems you saw in Hamlet?

~~~
Argorak
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. ;)

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

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

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

~~~
yogsototh
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/)

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

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

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

~~~
gregwebs
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
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?

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

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

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

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

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

~~~
cies
the hashing prevents tinkering/tampering

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

------
yummyfajitas
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
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
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
As someone who gave up on yesod because it is so railsish and moved to snap,
I'd say it is pretty accurate.

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

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

~~~
cies
lol.

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

It just looks awful.

~~~
dons
See also:

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

Design time!

~~~
cies
volunteering time! :)

------
grout
Doesn't build with the gold linker. Feh.

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

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

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

