5

There have been great things happening in the Haskell web development world, and some of the available frameworks (Yesod and Snap server) seem quite mature. However the learning curve can be a bit steep, and perhaps building web apps cannot quite be considered Haskell's forte.

The answer to another SO question of mine indicates that writing PHP extensions in Haskell should be possible. Infact I'm currently in the process of trying to convert a small Haskell program to a PHP extension as a proof of concept.

So, the question is - is there a case for creating a Haskell web framework that is meant to be run as a PHP extension and leaves all the request/response / cookies etc. handling to PHP?

What would be the design decisions involved in creating such a framework? Right now, the only thing I can think of is that it would probably expose an XML/JSON API accessible by the PHP pages using GET and SET function calls.

Improve this question
5
  • Specifically for PHP, I doubt it, just based on culture. But there might be some middleware that would end up working with php. Commented Jun 14, 2011 at 15:21
  • The learning curve for just using a bare-basics web approach on top of Happstack or Snap server alone is minimal. The complexity only comes with the various scaffolding for larger sites provided by snap or yesod along with various persistence approaches and opinionated templating systems. If you disregard that stuff (not so easy with yesod, but very simple with happstack or snap or even just fastcgi) then there's really no advantage to php. Commented Jun 14, 2011 at 15:36
  • @sclv: Eh? What's so hard about Yesod? I made some toy apps to try it out and it seemed really easy to get started with even without knowing what I was doing. Also didn't feel like it had any more black boxes full of black magic than, say, Rails. Admittedly I didn't go very far and didn't do much with persistence, so maybe it gets trickier at some point? Better documentation would have been nice, but I gather that's a work in progress. Commented Jun 14, 2011 at 16:43
  • @camcann -- I agree that yesod isn't more magical than rails. But then neither is david blaine. I don't think that e.g. type safe paths and hamlet and such are insanely hard. They're just different from what people are used to. So the work upfront for a "minimal" site involves a certain learning curve, and you only see the payoff for bigger sites. But that's not a Haskell issue -- the same is true of frameworks in Python or anything else. I took a look at the pylons documentation the other week and found it completely inscrutable. Commented Jun 14, 2011 at 17:13
  • @sclv: I guess so. It just seemed to me that most of the difficult things in Yesod can be used extensively without much understanding, largely deferring the learning curve. Obviously I'm comfortable with Haskell in general, and web development pays my bills, but I still have no idea whatsoever how Yesod's internals work. Yet I got pretty far with small sites just by crude imitation of examples I saw elsewhere. Commented Jun 14, 2011 at 18:04

1 Answer 1

Reset to default
10

I can't think of a use case where this makes any sense. If you want something else to handle the HTTP request/response, you'd be better off writing to the Apache API directly.

Introducing PHP gives you argument parsing and cookie handling but also introduces a lot of other silliness. Not only are many of the common practices very unsafe or insecure, but you are limited to content generation -- if you want to dispatch to other parts of code based on the URL you have to write all that yourself. Many mature PHP programs end up just having one "start" PHP script. You also will have problems if you want to do anything interesting with uploaded files, because PHP handles that in a suboptimal way.

You could theoretically do something very processor intensive in your Haskell extension, but you might as well just write a C extension for PHP in that case. And PHP invocations are never supposed to hang around for very long anyway.

Seems like you are limiting yourself to PHP's brain-damaged model of a web application for the very trivial benefit of argument and header parsing.

Writing a Haskell interface to the Apache API could potentially be liberating. You could rely on a battle-tested web server, and also hook into every phase of the Apache request cycle. Apache's way of preforking and killing children every now and then might be a way of dealing with Haskell space leaks, although it's a sledgehammer approach.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

In addition to this, if you use FCGI you could as easily make a module for nginx or LigHttpd. Both can be a better choice when you need to deploy a high load application and don't need all the heavy-duty stuff from Apache.