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

[Michael Snoyman]

On Mon, Mar 15, 2010 at 2:38 PM, Gregory Collins <greg at gregorycollins.net>wrote:

> 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.
>
> Maybe I'm misunderstanding you, but your whole e-mail seems like a large
contradiction. But firstly, I believe your premise is mistaken: we're not
trying to "standardize interfaces" for the most part; it's true that WAI was
such an approach, but that's not the focus of this thread. You claim that
anyone could write an adapter between two interfaces; look at the code for
hack-handler-hyena and you'll understand the folly of that sentiment. But
more to the point: because of WAI, we don't *have* to write the adapter, and
I don't see any substantive critiques of the WAI approach. (If there are, we
can address them by fixing the WAI.)

Now, let me try to understand your point here: we need standardized
interfaces for applications to communicate with each other, but we can't do
that until we have the low level interfaces hammered out. On the other hand,
you say that it's premature to try to standardize interfaces. And then you
make it clear that the use case of many people (shared hosting) doesn't
interest you at all; based on previous conversations, I believe this means
that Snap will have *no* (Fast)CGI support. So where exactly are you hoping
to create this platform from which everyone will build these great
applications that snap together so well?

I think (correct me if I'm wrong) that everyone else here is in agreement
that the goal should not be to create a great framework that will solve
everyone's needs. The goal should be to create great libraries that can be
used independently. For example, separating out happstack-server and
happstack-state now provides two great libraries that someone can use as
part of a completely different application stack.

I think that this approach is much healthier and productive than each of us
trying to create the greatest snappable framework ever and hoping everyone
else creates applications for it.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100315/3fec49db/attachment-0001.html