[Haskell-cafe] Haskell Web Framework

[John A. De Goes]

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  
JavaScript.

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/ 
JavaScript and similar projects, which compile Haskell to JavaScript  
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  
resources.

Regards,

John A. De Goes
N-BRAIN, Inc.
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  
> characteristics.
>
> 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.
>
> Michael
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe