I'm definitely interested in Yesod, and it's currently at the top of my rather short list of possibilities, but the relatively immaturity does worry me a bit, in particular as it pertains to my fourth requirement. I'm not opposed to making updates from time to time to keep the site current with the latest release, but I want to avoid having to constantly tweak things, and most importantly I don't want to end up in the situation where a year or two down the line the entire framework gets deprecated and I essentially endup having to re-write the entire site from scratch.
I should probably stress that I'm a relatively newbie to Haskell, and there's still a few things that I'm trying to get my head around. In particular I haven't had much chance to really look at TH, and my understanding of monads is a bit rocky in places although I've got the basic principle worked out. I'm further hampered in that I'm working on this project and other Haskell related things in my spair time which is rather lacking at the moment, so ease of understanding (I.E. good documentation) is a major bonus for me.
For persistance I'm not all that worried as I can just use one of the HSQL packages and one of the various SQL servers, although any support in the framework itself would be welcome.
Near as I can tell, the options for doing websites with Haskell can be boiled down to:
1) Happs(tack)
2) Yesod
3) Roll your own from low level components
and at least in the case of Yesod there's still a few components that are essentially roll-your-own, although I should point out I'm not opposed to that assuming there's some good examples available of exactly how to go about doing that. In particular I've been looking over the bug tracker and blog code based on Yesod.
-R. Kyle Murphy
--
Curiosity was framed, Ignorance killed the cat.
Hi Kyle,
Well, the web-routes-quasi package is basically an attempt to split out the quasi-quoting used in Yesod so that others can use it. The next release of Yesod will in fact depend on web-routes-quasi (in all likelihood).
The documentation on Yesod *is* sparse at the moment, mostly because the API is still immature and will have some major changes over the next few releases. If you're looking for something that will have backwards compatibility, Yesod is not for you at the moment.
I will say that I use Yesod in production on a number of websites, and it's worked well enough for me. One thing that it is majorly lacking is a persistence layer, but I'm working on that[1]. I also have been toying with the idea of replacing HStringTemplate with a type-safe templating system[2]; for fun I'm basing the syntax off of Haml[3]. If you want information on either of these projects, or have suggestions, I'd love to hear them.
If you have other concerns, I'm also interested in hearing them. Yesod is young and has plenty of room to grow, but I think it's a pleasure to program with and is filling a niche that is missed by other Haskell packages.
Michael
[1] http://github.com/snoyberg/persistent
[2] http://github.com/snoyberg/hamlet
[3] http://haml-lang.com/
On Wed, Apr 7, 2010 at 10:46 AM, Kyle Murphy <orclev@gmail.com> wrote:_______________________________________________I'm looking at experimenting with developing a site and due to various constraints I'm considering using one of the haskell frameworks. I experimented a bit with Happstack, although I'm not all that happy with it and I'm interested in alternatives. I've also looked briefly at yesod but it doesn't seem to be very well documented and I've got some concerns. The environment I'm working in has constrained memory, about 300M physical, with a further 500M of swap, but a relatively beefy CPU, so I'm trying to stay away from any of the in memory systems like MACID in happstack. At this point I'm mostly toying with the different frameworks to try to get a feel for them, but in a couple months I'm probably going to need to actually put together a production system that can handle some fairly low duty e-commerce. I'm planning on using Google Checkout for order processing, but aside from that and the memory constraints I don't have any real hard rules for what the framework needs to support. I'm currently running nginx to serve static content on the server, so I could potentially integrate with that, or I could just have whichever framework I end up using serve the static content as well.
So, my requirements are as follows:
1) Small memory footprint
2) Relatively simple to extend such that I can integrate it with Google Checkout
3) Documented well enough that I can figure out how to plumb everything together without needing to dig through the guts of the framework
4) Relatively stable such that a year from now I don't need to re-write the entire site because the framework isn't maintained an no longer works on the current version of GHC.
Any suggestions?
P.S. I'm interested in the quasi-quote package I saw mentioned here recently, but it looks more suited for use by framework developers rather than as a finished component, at least from the limited info I've found.
-R. Kyle Murphy
--
Curiosity was framed, Ignorance killed the cat.
web-devel mailing list
web-devel@haskell.org
http://www.haskell.org/mailman/listinfo/web-devel