[Haskell-cafe] Haskell Web Framework
John A. De Goes
john at n-brain.net
Mon Jan 26 12:37:42 EST 2009
The best approach is to push as much functionality into the client as
possible. The ideal server-side framework consists of nothing more
than a permissions-based interface to persistence and network
services. That's it. Everything else is done on the client side, in
Web designers can pretty easily style dynamically generated HTML, if
the semantics are good -- you just need to let them capture that HTML
in any given part of the application.
What this means is that effort is probably best directed at Yhc/
for execution on the client. Sure, some server-side work needs to be
done, but it's extremely minimal. Far more needs to be done on the
client-side. There's not many people working on that and the
infrastructure is in need of more creative input and development
John A. De Goes
The Evolution of Collaboration
http://www.n-brain.net | 877-376-2724 x 101
On Jan 25, 2009, at 10:54 PM, Michael Snoyman wrote:
> I´m working in a web application rather than a web framework. But I
> sometimes think about how a complete web application server should
> be. For my case, I don´t care about the presentation, because HSP is
> more than enough. However, I need active-active clustering,
> distributed transactions and workflows. I have created the module
> Workflow for the latter. For the former, I developped TCache, that
> is a transactional cache using STM, with configurable persistence. It
> ´s like hibernate for Java and (the data part of) Rails for Rubi.
> Now I´m working in a extension of TCache with distributed
> transactions and remote clustering with some additonal interesting
> That all sounds like something that would fit very nicely into this
> framework that I'm addressing.
> My own view about haskell and Web applications is that something
> like " a web framework" is not in the philosophy of Haskell. What
> is in the philosophy of Haskell is the creation of modules that the
> people can combine to create their own web frameworks.
> I agree to a certain extent. If you look at the code that I've
> written so far, it's in "layers." The bottom layer defines a Request
> and Response object, defines a service as "Request -> IO Response",
> and a server as something as essentially "Service -> IO ()". The
> next layer is a controller which is itself a service. View details
> are built on top of this.
> In your case, you could bypass all the controller logic if you like
> and simply deal with the server definition. You would get the
> advantage of having your app work as a standalone server, a CGI
> program, FastCGI, or anything else that people write adapters for.
> Someone else might decide to use the the controller and ignore the
> specialized view code (they really like dealing with straight
> Strings perhaps).
> However, I think we should develop a full stack so that it is
> available for those that want it. From my Django experience, I must
> say that very few things are cooler than calling a script which
> automatically generates all the boilerplate code inherent in every
> web app. I think those features should be available to those who
> want it (even if it's not in the spirit of Haskell), while those who
> want to treat the "framework" as a set of libraries need not been
> hindered by the extra features.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe