Comparing Haskell's Snap and Yesod web frameworks

Question

The two Haskell web frameworks in the news recently are Yesod (at 0.8) and Snap (at 0.4).

It's quite obvious that Yesod currently supports a lot more features than Snap. However, I can't stand the syntax Yesod uses for its HTML, CSS and Javascript.

So, I'd like to understand what I'd be missing if I went with Snap instead. For example, doesn't look like database support is there. How about sessions? Other features?

Solution 1

Full disclosure: I'm one of the lead developers of Snap.

First of all, let's talk about what Snap is. Right now the Snap team maintains five different projects on hackage: snap-core, snap-server, heist, snap, and xmlhtml. snap-server is a web server that exposes the API defined by snap-core. heist is a templating system. xmlhtml is an XML/HTML parsing and rendering library used by heist. snap is an umbrella project that glues them all together and provides the powerful snaplets API that makes web apps composable and modular.

Yesod has a host of projects on hackage. Most (all?) of them are listed in the Yesod category. Some of the notable ones are yesod-core, warp, persistent, and hamlet.

The reality of Haskell web development is that it's much less of an exclusive-or choice than seems to be perceived. In general the projects are very loosely coupled and fairly interchangeable. You could build a website using warp (the Yesod team's web server), heist (the Snap team's template system), and acid-state (the Happstack project's persistence system). You could also use snap-server with hamlet or persistent.

That said, the two projects definitely have some differences. The biggest difference I can point out objectively is that Yesod projects typically make heavy use of Template Haskell and quasiquoting to create concise DSLs, while Snap projects stick to building combinator libraries that favor composability. Just about any other differences I can think of will be subjectively biased towards Snap. The umbrella packages named after both projects are obviously going to make specific choices for the above mentioned components, and these choices will be reflected in the project dependencies. But that still doesn't mean that you can't pull in something different and use it as well.

Snap does have sessions and authentication, interfaces to several databases, and nice form handling (here and here) using digestive-functors that includes prepackaged support for arbitrarily nested dynamically sizable lists. These are just some of the growing ecosystem of pluggable snaplets. The sessions and authentication snaplets are written in a way that is back-end agnostic. So with a small amount of glue code you should be able to use it with just about any persistence system you can think of. In the future, Snap will stick with this policy as often as possible.

For the most part I think the choice of Snap vs Yesod vs Happstack is less an issue of features and more one of personal taste. Whenever someone says that one of the frameworks doesn't have something that another one has, most of the time it will be pretty easy to pull in the missing functionality from the other framework by importing the necessary package.

EDIT: For a more detailed comparison of the big three Haskell web frameworks check out my recent blog post. For a rougher (but possibly more useful) comparison using some broader generalizations, see my Haskell Web Framework Comparison Matrix

Solution 2

Fair warning: I'm the lead developer of Yesod.

I'm not sure what you don't like about the Javascript syntax: it is plain javascript with variable interpolation. As for CSS Yesod now has Lucius which allows you to also use plain CSS. For HTML, you can easily use any other library you want, including Heist (what Snap uses). That said, it's a bit of a funny thing to skip Yesod over CSS/Javascript syntax, when Snap doesn't even have a syntax for it. You are certainly welcome to their solution of just static files.

Yesod comes with seamless support for authentication/authorization, type-safe URLs, widgets, email, and a bunch of little things all over the place (breadcrumbs, messages, ultimate destination). Plus, Yesod has a fairly rich set of add-on packages for things like comments and markdown, and a few large real-world code bases to pick at for examples. If any of these are attractive to you, you might want to check if your alternatives supports them.

Solution 3

Give hamlet a try- you might end up liking it. A negative reaction at a superficial level is not uncommon. However, nobody that has actually used hamlet complains.

Also, why not use Happstack? Just because they aren't "in the news" doesn't mean they don't have a solid framework.

Solution 4

You probably referring to old version of yesod. Latest yesod versions have plain syntax for html, javascript and css.

The html syntax of yesod's template library hamlet is plain html with complete opening and closing tags and all normal html attributes. Yes you can omit closing tags and use shortcuts for id and class attributes. But you do not have to. You can continue to write plain html.

Not only that but html templates can reside in separate files, just like in Snap's template library Heist.

Java script templates (julius) are plain javascript files, also residing in separate files.

The css template does indeed have a different syntax, but recent version of yesod now provides also plain css syntax.

If you go with Heist you will not have type safe urls.

In Heist html templates are read from harddrive everytime. Yesod compiles all templates directly into the executable. No file is read from harddrive. Thus the response is much faster. You can see the benchmarks yourself.

In Yesod you can create widgets that cooperate nicely. Snap does not deal with widgets at all. You will have to roll your own.

View more solutions

Comments

[Rehno Lindeque]

Personally I can't stand the syntax that html uses for html ;)

[max]

what do you not like about the hamlet template syntax for generating html?

[Muchin]

I don't like that I can't move between Dreamweaver and Yesod because the syntax is different.

[Michael Snoyman]

In general, the Yesod team is very open to new ideas. Now that I know your use case, I can probably recommend a good solution for you. It would be best if you send an email to the web-devel list, as SO isn't the best place for a collaborative discussion.

[OJ.]

People still use Dreamweaver? ;)

[gawi]

Why was this question tagged "web-services"?

[Abhijit Sarkar]

A good question that'd be shut down in no time if asked today. Sadly, no space for thought provoking questions on SO anymore.

[mightybyte]

As I describe above, your comment about type safe URLs is incorrect, and helps perpetuate the misconception I mention. It would be more accurate if you said "Heist" instead of "Snap".

[Vagif Verdi]

Type safe urls are possible due a combination of template engine AND routing mechanism. So it's not only Heist. You will not get type safe urls in Snap just by using hamlet.

[mightybyte]

I'm not talking about hamlet. The web-routes package was originally written for Happstack which has essentially the same routing interface that Snap has. You'll probably need a little glue code, but that's pretty much always going to be the case.

[Michael Snoyman]

I wouldn't make such a small point of that "glue code." The Template Haskell that you refer to below is what makes that "glue code" possible in a safe, concise manner. I wrote a small blog post to address that: yesodweb.com/blog/yesod-template-haskell

[Michael Snoyman]

It's very new, I haven't had a chance to update the documentation yet. But basically, just type in normal CSS, and use #{...} and @{...} for interpolation just like Hamlet/Cassius/Julius. Nesting is also supported, but that will take a little more space to explain than this comment ;). If you email web-devel, we can give you some more details there while the documentation catches up.

[sclv]

For those who want to go with another (weaker, but more flexible) templating approach, HStringTemplate also plays well with all frameworks, as far as I know, and allows reading templates on the fly for development, caching them for production, and also compiling them in via quasiquotation if desired. The qq support is maybe 13 lines, and I have no doubt heist could add it trivially, were there demand.

[max]

a maintainer of yesod suggesting giving a competing framework a try. what a great community we have.

[Andras Gyomrey]

Any change to use Julius without code being compressed? I'm usig Google Closure and I need to keep metadata in comments for the compiler.

[Michael Snoyman]

I don't think this is a good place to discuss such a thing, but there's no requirement to have Julius code be compressed (it doesn't do it by default). If you need more assistance, a separate SO question or a mailing list thread would be a better bet.