[web-devel] On the state of Haskell web frameworks

Gregory Collins greg at gregorycollins.net
Mon Mar 15 18:38:47 EDT 2010

Hi all,

Just subscribed, and after reading through the recent traffic on this
list in the archives I have a couple of quick comments.

First, and I've discussed this with Michael Snoyman at length in
private, I agree 100% with Chris Eidhof when he writes "I don't believe
that there could be one big framework for everybody." Even getting
consensus on what the prerequisites would be is basically impossible. To
quote Gour:

> Although it might be great framework, I'll be frank to say that
> Happstack with all technology that goes along is something which is
> either too complicated for me, not practical to be run on shared
> hosting (e.g. Webfaction), not documented properly and it belongs to
> 'noSQL' which is not for me at the moment.
> That's why I'm interested to discuss possibility to somehow
> consolidate Haskell's web frameworks nad provide something which is
> good for practical development, does not require VPS to be used, nice
> documentation etc.

A priori we've reached a fundamental disagreement about first principles
-- personally I couldn't give a rat's ass whether the framework I'm
using runs well on shared hosting, my focus is on being able to
efficiently service heavy loads in a production context. Obviously, on
the other side of the coin, being able to run in a CGI process hooked up
to Apache is really important to many people.

Michael wants to use YAML to define data models: more power to him, but
personally the idea of doing that makes me want to vomit. I'm not saying
that to disparage him at all, the idea isn't necessarily bad on its own
merits: it just isn't for me. Everyone has their own pet preferences.

I'm seeing a lot of energy being dedicated to standardizing interfaces,
which I suppose is an admirable goal, but to me it's putting the cart
before the horse: what's the point of having a standardized adapter when
there's nothing worth plugging into it, besides some middleware that
your framework should be providing for you anyways? Concentrating too
much on interop right now is a waste of time IMO - besides, on the level
that it's currently being discussed, that stuff is *easy*: making an
adapter between any two of the myriad different web stack
implementations (WAI, Happstack, Hyena, CGI, Hack, FastCGI, etc etc etc)
is trivial. I doubt there's anyone on this list who couldn't cook up a
WAI/CGI gateway in an afternoon.

We need pluggable *applications* (blog, CMS, RSS feed generation,
administrative panels, forum, wiki, caching, user management, etc) that
understand how to talk to each other --- expecting "plug and play"
compatibility between frameworks on this level, when there's no
consensus on the *primitives*, is a pipe dream. The first framework that
cracks this particular nut, in a way that makes it easy and pleasurable
for people to build web apps that perform, is going to gain a lot of
traction. Code talks.

Gregory Collins <greg at gregorycollins.net>

More information about the web-devel mailing list