Re: [web-devel] Hoogle Advice

On Tue, Jan 25, 2011 at 3:14 AM, Jeremy Shaw wrote:

On Mon, Jan 24, 2011 at 4:38 PM, Neil Mitchell 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. :)