[web-devel] Hoogle Advice

[Michael Snoyman]

On Tue, Jan 25, 2011 at 3:14 AM, Jeremy Shaw <jeremy at n-heptane.com> wrote:
> On Mon, Jan 24, 2011 at 4:38 PM, Neil Mitchell <ndmitchell at gmail.com> wrote:
>
>> I think WAI could be increasingly used - its at a level of abstraction
>> that I quite like. I certainly have other projects which I will
>> probably switch over to WAI/Warp.
>
> I am curious to see how your feelings on this change or stay the same over time.
>
> The basic WAI abstraction is very nice. You essentially supply a
> function, Request -> IO Response, that will be used to handle incoming
> Requests. It is very straight-forward and obvious what is going on. At
> first this is very attractive. It makes it very easy to get started.
>
> But at the same time, it doesn't do much for you.. I wonder if you
> will ultimately end up recreating a higher level framework in your WAI
> based applications. For example, you might decide that passing the
> Request around explicitly is tiresome and stick it in a Reader monad.
> When looking up key/value pairs from the query string or post data,
> you might want more expressive combinators for validating the values
> and converting the string data to haskell types. You might find that
> sometimes you need to escape early and return an alternate page. You
> might realize that the Response is going to need some extra headers
> (like the Cookie field) but be in a spot in your code where the
> Response has not been created yet. So you will need a filter, or
> something, that can add the header later when the Response is created.
> And, of course, you need some way to look at the pieces of the url and
> map it to a handler.
>
> These are the types of features (and more) that exist in the
> higher-level frameworks like Happstack, Snap, and Yesod. In theory,
> that is the value they add over just using WAI. It is likely that, in
> the future, happstack will not include it's own http backend, but be a
> layer on top of WAI+warp, hyena, or some other low-level WAI-like HTTP
> backend. So, I am curious if the value-added features we provide
> actual provide value :)  One measure of this will be if you end up
> creating similar adhoc functions and structure in your apps.
>
> - jeremy
>

I personally agree with this sentiment to some extent: those who don't
use a framework will be doomed to reinvent one. Nonetheless, I see two
very compelling reasons for people to skip the frameworks entirely:

* They are writing a site that involves very few of the features
offered by a framework. For example, no routing, no persistence, no
templating. In such a case, it's likely that a framework will simply
get in their way.
* Haskellers tend to be an "opinionated" bunch, so it's not surprising
that any random Haskeller may disagree with the design decisions of
specific frameworks.

Can you honestly tell me that you think Happstack is that right tool
for every site? I can definitely say that- as much as I like Yesod-
there are use cases that it simply is not intended for. Even if I
*personally* would likely still use Yesod for those, that's just
because I'm so intimately familiar with the framework that I know all
the right places to make modifications to get it to do exactly what I
want. For someone coming from the outside, I think skipping the
framework in those cases is the right decision.

That's one of the main reasons I've designed Yesod and WAI the way I
have. By splitting the project up into so many pieces (Hamlet,
Persistent, authenticate, etc), users get to pick and choose exactly
what they want. Sure, as a framework author I would prefer them using
the whole stack, but as someone trying to push Haskell into more
mainstream use[1], giving people choice here is best.

It's very likely that Neil may end up reinventing a lot of the
features of a framework in this Hoogle project. But I *still* think
this is a good thing:

* He's now providing valuable insight into how WAI can be improved for
this new use case for which it was not designed.
* If he is so inclined, he could release this "boilerplate" code into
a separate package and, walla, we have a *new* Haskell framework,
building on top of what we have already, that caters to a new
audience.
* And even if none of that happens, it probably took him less time to
rewrite the features he needed than go through either the Happstack or
Yesod tutorials. For someone developing lots of sites, the learning
curve is IMO worth it; for a one-off project, I doubt it is.

I don't like seeing a fractured community, but I think this is exactly
the opposite effect: we're seeing new levels of integration of
pre-existing tools than we saw before.

Michael

[1] Sorry to those offended by the thought of mainstream Haskell. :)