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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

We're talking about web applications and Web 2.0 sites, which is the principal target of Rails and its ilk. For primarily static content- oriented sites, static HTML works just fine, but even in this case, you can do dynamic transformations on the HTML in order to provide a richer, more user-friendly surfing experience. It's only a matter of time until browsers provide better accessibility for web apps and search engines start indexing JavaScript-generated content. The era of HTML templates and heavy server-side HTML is coming to a close, for all but static content-oriented websites. The whole industry is moving in a dynamic direction (along with developer tools and libraries), and it would be a shame if a bunch of Haskell developers got together to write a really great Haskell web framework for the Internet as it was 5 years ago. Times have changed. Haskell -> JavaScript is a much more fruitful direction to pursue, I think. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Jan 26, 2009, at 10:49 AM, Michael Snoyman wrote:

On Mon, Jan 26, 2009 at 9:37 AM, John A. De Goes wrote:

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.

That's great in theory, but then you end of with inaccessible web sites, those without Javascript are left out in the cold, and search engines won't index you. I think any framework should transparently make a site work the way you describe and as plain HTML.

On Tue, Jan 27, 2009 at 3:05 PM, Michaeljohn Clement wrote:

John A. De Goes wrote:

...

There is very little wrong with ECMAScript if people would only learn it properly and play to its strengths instead of trying to turn it into things it is not.

Treating ECMAScript as a compiler target language will be a win eventually, I expect, but not by compiling from Haskell. Haskell could certainly play a role, e.g. as an implementation language for ES-to-ES or DSL-to-ES compiler writers.

... -- Michaeljohn Clement _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Javascript itself is such a versatile language I don't think it needs to be hidden by a DSL, but, as you mentioned an ES-to-ES wrapper, with the exception that the framework could auto generate a few helper functions on the client side. I think the optimal approach is to create a sort of generator of "client" applications. These applications will use XHTML for graphical structure and Javascript for logic. The haskell framework would streamline the creation of dynamic HTML and offer a fast and simple means of specifying an RPC interface from the client to the server. It would also make sense to leverage an existing set of libraries for this purpose. JQuery RPC is fantastic (as is the rest of JQuery) and, IMO, it provides enough abstraction to make Javascript tolerable for any type of programmer. Using the Client/Server paradigm, one could gain additional performance benefits from templates. Since all of their dynamic state is set an runtime via javascript, they can all be precompiled into XHTML and JS. To avoid the initial request for values after the page load, an appendix could be sent from the server with the XHTML file that automatically sets all of the dynamic values. I have been slowly building a proof of concept of these ideas using HAML as the template engine and JQuery.RPC as the communication mechanism. It's not intended to be a full framework, but a client generator that could make JSON RPC requests to any RESTful interface (sorry for the buzzwords) I'll yell when I have something to show.