On Mon, 24 May 2010 17:47:53 +0300

...

...

...

...

...

"Michael" == wrote:

Michael> I would say that Yesod and Snap are very orthogonal Michael> projects. Without offense to the Snap authors, I don't really Michael> think Snap is a framework; it's much more low-level than Michael> that. As they put it, it's at the level of a Java servlet Michael> container. In that sense, it's slightly higher-level than Michael> WAI, but far more low-level than Yesod (or turbinado, Michael> happstack, etc). I'd agree with that, but they say: "Higher-level facilities for building web applications (like user/session management, component interfaces, data modeling, etc.) are planned but not yet implemented..." and, moreover, they aim at: "Snap aims to be the de facto web toolkit for Haskell... ", so it looks that present release is not the end of the story. Michael> I did some work after the Snap release to actually get Yesod Michael> running on top of Snap. Gregory has been very helpful, and Michael> will hopefully be releasing a newer version of snap-server Michael> that provides the functionality I'm missing. (Basically, Snap Michael> processes url-encoded form data, while WAI specifies that the Michael> POST body be passed to the application.) Would it be better option for shared-hosting scenario and FCGI serving? Michael> * Yesod uses the WAI definition of enumerator while Snap uses Michael> the iteratee package. The former is much simpler, the latter Michael> more powerful. I'd be very interested in a performance Michael> comparison of the two, my instinct tells me the former wins. I haven't been able to grok either of them...all I can say is that I understand this is hot topic in Haskell, and if one wants to dive into web development with Haskell, there is need to understand them more (hopefully not fully). Michael> * Snap has Heist, which is an XML based templating system, Michael> while Yesod uses Hamlet. However, neither framework is Michael> actually tied down to these templating systems. In fact, Snap Michael> doesn't even depend on Heist. Hamlet looks cool to me... /me does not like XML stuff... Michael> * Yesod has type-safe URLs, I don't believe Snap has any Michael> similar feature. Hmm, this is an important issue and one of the selling tickets to use Haskell instead of e.g. Python/Django (which we recently abandoned). Michael> * Some design decisions, notably they use a mutable states for Michael> modifying request and response values while Yesod uses a Michael> Reader for the request, and writer for response headers and Michael> actually returns a value for the response body/content type. What are some of the implications of the above design difference? Michael> I'm sure there are many more differences, but the main point Michael> is this: these two projects are very different types of Michael> frameworks. And I hope and expect that the two projects will Michael> have some cross-polinization going forward (in fact, we Michael> already have). Thank you for the input. It looks that it would be nice to make another comparison when (hopefully) Snap gets some more higher-level stuff and when Yesod will have some solution for persistence (hopefully with the ability to use RDBMS). Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------

On Mon, 24 May 2010 19:20:02 +0300

...

...

...

...

...

"Michael" == wrote:

Michael> Snap is definitely *not* geared at shared hosting. I Michael> discussed this with Gregory a while ago, and unless he's Michael> changed his mind since, they're not interested in anything Michael> but dedicated hosting. So I would definitely say stick with Michael> FastCGI (or CGI... I'm working on some benchmarks right now). I've asked the other day on #snapframework, and the response was "that use case is not very relevant for any of us but we know people are interested in that", so it does not sound as definite 'no', but who knows... Michael> > I know that since implementing this feature in Yesod it's > Michael> completely changed the way I write web apps. There's no more Michael> fear of changing my URL structure: I just do it, and the Michael> compiler tells me if I need to fix anything. If Yesod goes in Michael> the advertising direction, this will most likely be the top Michael> item on the list. Why should Yesod not go into (more) advertising? ;) Michael> > I personally prefer the Yesod approach, but of course I'm a Michael> > biased source. Michael> I found writing code against Snap to be a little... unnatural. I did not try (hard) enough neither with Yesod, nor with Snap, but none did not look 'natural' to me either. Maybe it's because I did not do any web programming and being only exposed to Django-way of things. We hope it will change when we go deeper... Michael> > Given my current line of employment, RDBMS is my top Michael> priority for the persistence layer. My thought right now is Michael> to start with MySQL, since it has the weakest Haskell support Michael> at the moment. Heh, I vote for PostgreSQL although sqlite3 would be probably enough to serve blog(gy), but I assume those will be supported as well. Michael> Ideas are percolating, but I haven't had a chance to actually Michael> write something concrete yet. OK. Wish you some 'enlightenment'. ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------

Gour writes:

On Mon, 24 May 2010 17:47:53 +0300

...

...

...

...

...

> "Michael" == wrote:

Michael> I would say that Yesod and Snap are very orthogonal Michael> projects. Without offense to the Snap authors, I don't really Michael> think Snap is a framework; it's much more low-level than Michael> that. As they put it, it's at the level of a Java servlet Michael> container. In that sense, it's slightly higher-level than Michael> WAI, but far more low-level than Yesod (or turbinado, Michael> happstack, etc).

I'd agree with that, but they say: "Higher-level facilities for building web applications (like user/session management, component interfaces, data modeling, etc.) are planned but not yet implemented..." and, moreover, they aim at: "Snap aims to be the de facto web toolkit for Haskell... ", so it looks that present release is not the end of the story.

Gour is correct here. We thought long and hard about how to balance the advantages of "release early and often" with the advantages of not releasing a half-baked product that turns people away for good. We decided to err by being more of the latter. In fact, Don Stewart expressed some concerns about our use of that approach. So we decided to get the low-level parts mature before release. Now we're getting these "snap is not a high level framework" opinions, which almost suggest we should have waited longer. I don't actually think that, but you have to wonder.

Michael> I did some work after the Snap release to actually get Yesod Michael> running on top of Snap. Gregory has been very helpful, and Michael> will hopefully be releasing a newer version of snap-server Michael> that provides the functionality I'm missing. (Basically, Snap Michael> processes url-encoded form data, while WAI specifies that the Michael> POST body be passed to the application.)

Would it be better option for shared-hosting scenario and FCGI serving?

VPSs these days are cheap enough that we decided not to address the shared-hosting demographic.

Michael> * Yesod uses the WAI definition of enumerator while Snap uses Michael> the iteratee package. The former is much simpler, the latter Michael> more powerful. I'd be very interested in a performance Michael> comparison of the two, my instinct tells me the former wins.

We'll have to see...

Michael> * Snap has Heist, which is an XML based templating system, Michael> while Yesod uses Hamlet. However, neither framework is Michael> actually tied down to these templating systems. In fact, Snap Michael> doesn't even depend on Heist.

Hamlet looks cool to me...

/me does not like XML stuff...

I don't care for HAML. I'd rather my templates be in the same general form as my end-result markup. Heist makes it trivial to implement extensions to XHTML ala the pattern used by Facebook for their FBML. So the approach is not without precedent. That said, I believe this is the most common complaint about Snap that I've seen. As we've already shown, it's not a valid complaint about snap-core and snap-server. But if you don't like XML templates, then Heist is not for you. To each his own.

Michael> * Yesod has type-safe URLs, I don't believe Snap has any Michael> similar feature.

Hmm, this is an important issue and one of the selling tickets to use Haskell instead of e.g. Python/Django (which we recently abandoned).

Awhile back I wrote a blog post about this question. (http://softwaresimply.blogspot.com/2008/03/to-template-or-not-to-template.ht...) My conclusion then was in favor of haskell-generated markup. This led me to really want something for type-safe URLs. I never got around to implementing something, but I wished for them on many occasions. After building and running a website on happstack using this approach, I have changed my mind. I think that abstracting the generation of a site's markup is very site-specific, and difficult to get right. Type-safe URLs are a nice bonus, but I don't think they're enough to tip the scales. That said, my only experience with a templated site snapframework.com, so I still have more to learn. But so far working with Heist templates has been quite nice. I'm planning to do a blog post on this sometime (hopefully near future). So this whole issue is very debatable. But again, snap-core and snap-server can be used with either approach.

Michael> * Some design decisions, notably they use a mutable states for Michael> modifying request and response values while Yesod uses a Michael> Reader for the request, and writer for response headers and Michael> actually returns a value for the response body/content type.

What are some of the implications of the above design difference?

I don't think this is a significant difference. Using state instead of reader hasn't changed Haskell into an impure language. And you can make readers behave like a state monad using the local function.

On Mon, May 24, 2010 at 7:47 PM, Chris Smith wrote:

Just one comment (in a few parts).

On Mon, 2010-05-24 at 17:47 +0300, Michael Snoyman wrote:

...

I would say that Yesod and Snap are very orthogonal projects. Without offense to the Snap authors, I don't really think Snap is a framework; it's much more low-level than that.

That seems to be overstating the case a bit. Snap is designed to write applications directly on top of it, and in that sense acts as a framework. Some of the difference you're seeing likely comes down to preference about how heavy the "framework" ought to be.

...

* Yesod has type-safe URLs, I don't believe Snap has any similar feature. However, as I mentioned already, Snap is lower level than Yesod, so you could easily implement type-safe URLs on top of Snap.

Snap does provide a form of routing requests, and even of parsing data from the contents of the URL. It looks to be based on combinators similar to what Happstack does, with the exception that capturing variables from URLs is done in a relatively braindead way by adding special syntax with colons inside strings.

The point here is, Snap does something different; not necessarily something worse. We all have our preferences. Treating Snap as a new underlying server implementation on top of which to layer WAI and Yesod is possible, but rather missing the point. Much of what I get from Snap is that we can dispense with some of the unnecessary complexity and just solve problems.

Then again, I've also built three or four significant internally used web applications with Happstack, and have yet to use happstack-state for anything but working through tutorials. Could be I'm just afraid of change...

I think you read my e-mail a little too harshly. Let me rephrase:

* The feature set Snap has right now does not qualify it as a framework *in my mind*. If someone asks to compare the features of Snap and Yesod, there's not much to say. I'm well aware of the subjectivity of the term framework, I'm merely saying that by the criteria I know, and which I think most people are used to, Snap does not provide the features of a framework. * I'm well aware of Snap's routing abilities, but it still does not support type-safe URLs. You may not want type-safe URLs, that's fine. But I can't compare Yesod's implementation of them versus Snap's, simply because the latter is absent. If you see Snap as a great way to write applications without complications, go for it, I think that's great. For people that want features that Yesod provides, I think it will be nice to have a fast server to run on top of. Michael

Sorry for appearing in the middle of the discussion but, On Mon, May 24, 2010 at 9:10 PM, Gour wrote:

/me just wants rich Haskell framework being able to deploy on shared hosting usign RDBMS so that we can stop looking at the Python's courtyard.

Don't you think, that ability to deploy on shared hosting is overvalued feature, I mean VPS are quite cheep and that's definitely not an issue to buy one and setup your web application with your favourite web-framework. Python people don't bother about shared hosting solutions, while Python implementation are much slower than GHC ;-). Related to URL routing solutions in Yesod and Snap — I've found the Snap way to be more comfortable, maybe this is because the same syntax is used by Python/Ruby web frameworks (I personally have experience with many Python web frameworks). Also I don't think that URL routing type safety is also very important here. Thanks! -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8mayday@gmail.com

On Mon, May 24, 2010 at 8:49 PM, Gregory Collins wrote:

Andrey Popp <8mayday@gmail.com> writes:

...

Related to URL routing solutions in Yesod and Snap — I've found the Snap way to be more comfortable, maybe this is because the same syntax is used by Python/Ruby web frameworks (I personally have experience with many Python web frameworks). Also I don't think that URL routing type safety is also very important here.

There is actually nothing stopping us from providing a typesafe URL routing engine; we just haven't done it yet because like you, it isn't very important to us. Some people really like it though, so I can see us providing something eventually.

I'm just curious if anyone's actually *used* type-safe URLs in production web apps. I'm not really aware of an implementation besides what Jeremy Shaw has done (first urlt and then web-routes). I'm afraid that the technique is not getting the credit it deserves.

When I say type-safe URLs, I'm talking about having a datatype which represents all possible routes in an application, a function to convert from that datatype to a String, and a function to attempt converting a String to that datatype. As a simple example: data MyBlog = BlogHome | BlogEntry String | AtomFeed Then, instead of typing something like "/entries/" ++ entryName ++ "/", you just type BlogEntry entryName. In this simple case, it doesn't do much more than ensure you don't make typos. I can't go into details, but I had a project where I needed to change an entity relationship from many-to-many to many-to-one, and suddenly I had to remove an extraneous parameter from all of my routes. Due to type-safe URLs, I changed the datatype and the compiler caught each and every time I needed to modify the code. More simply, if I decide suddenly to rename "/entry/1/" to "/post/1/", I only need to change the URL rendering function and all of my code is updated automatically. This monologue isn't meant as a Yesod-is-better-than-Snap, it's meant to point out that type-safe URLs are a very powerful feature, and I think it fits very nicely with the Haskell nature. I'd really urge people to look hard at them and consider using them. Michael

Michael Snoyman writes:

This monologue isn't meant as a Yesod-is-better-than-Snap, it's meant to point out that type-safe URLs are a very powerful feature, and I think it fits very nicely with the Haskell nature. I'd really urge people to look hard at them and consider using them.

Enough people want this that I've been talking with Jeremy about doing a web-routes backend for Snap -- sounds like less than an hour's work. On the todo list... G -- Gregory Collins

Absolutely, that was a primary design goal. There's really two packages at play here: * Jeremy Shaw's web-routes provides some basic infrastructure. * My web-routes-quasi provides the quasi-quoted syntax and template haskell code for generating the render, parse and dispatch functions. Currently web-routes-quasi is pretty tailor-made for Yesod, but I'd be happy to make changes to have it fit your needs. I originally wanted the package to be more general, but realized I really needed user feedback on the features desired in order to do that properly. Michael On Tue, May 25, 2010 at 2:10 PM, Alberto G. Corona wrote:

Could your web-routes be general enough to be integrated in other frameworks?. du to my special requirements I´m working on my own app-server (persistence, clustering, state, threading, but not web framework) and I would like to have web components available to put at the top, rather than web frameworks.

Alberto

2010/5/24 Gregory Collins

...

Michael Snoyman writes:

...

This monologue isn't meant as a Yesod-is-better-than-Snap, it's meant to point out that type-safe URLs are a very powerful feature, and I think it fits very nicely with the Haskell nature. I'd really urge people to look hard at them and consider using them.

Enough people want this that I've been talking with Jeremy about doing a web-routes backend for Snap -- sounds like less than an hour's work. On the todo list...

G -- Gregory Collins _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

On Mon, 24 May 2010 21:35:04 +0400

...

...

...

...

...

"Andrey" == Andrey Popp <8mayday-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Andrey> Don't you think, that ability to deploy on shared hosting is Andrey> overvalued feature, I mean VPS are quite cheep and that's Andrey> definitely not an issue to buy one and setup your web Andrey> application with your favourite web-framework. Python people Andrey> don't bother about shared hosting solutions, while Python Andrey> implementation are much slower than GHC ;-). No! It is not question about cheap or expensive hosting, but, in my case, my time that should be used for maintaining the whole VPS (mail server, database server etc.) plus security issues etc. is more precious than cost of the hosting. Otoh, with e.g. Webfaction I get all these for free, taking care only about web-stuff. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------