Hi, I do appreciate the argument that I am likely to do lots of things that may benefit from a framework, and I have somewhat developed a framework for Hoogle. It has 3 layers, each calling the one below. :: IO () -- run a web server :: CmdLine -> Request -> IO Response -- deal with request/response, this layer is about 15 lines :: Database -> Query -> String -- the actual logic The first layer has been mostly replaced by WAI/Warp. The second layer is very small, and I don't think has any bits in it that could be abstracted. In the third layer the only feature I might make use of from a web framework is some templating library. Previously the third layer made use of trhsx, the XML in Haskell dialect, but then I switched back to just building strings. (I will probably change the String return to Builder at some point, or switch to a templating library.) Given that Hoogle does a lot more back end processing, and not so much serving of images/form submission/websity things etc.I think the use case for a framework would be limited - there just isn't enough code to get any gains - my .cabal file would probably grow more than my lines of code decreases :-) If in future Hoogle becomes more webby, gets more web features, I might grab more bits of web framework into the mix.
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.
I am a big fan of the Yesod approach of lots of small components, that can be used separately, but also integrate nicely. If I ever go shopping for a template library I'll certainly be looking for something with similar properties. Thanks, Neil