Flapjax, in its current state, is useful in writing client side (xhtml) applications that use generic web services (yahoo, google, netflix, etc) or specialized ones (a persistent store). Similar applications, though much less rich, could be written with PLT scheme server if PLT replaced all IO, SQL, etc libraries with our 3 read, write, and webservice primitives, + the corresponding security policy reflection ones. If a computation *must* occur on the server, then I suspect the requirements for describing that computation are entirely different. Why must a computation occur on a server? Probably because it needs to do privileged operations (aggregating data, using system resources, etc) or one of the many reasons people love Erlang. My instinct, at this point, is to say different solutions to different problem domains. A single, integrated client/server system sounds like a great idea: then we can get systems like HaXe where we can compile to js or flash. If we pay attention to Dan Weld's work, we would even serve up the proper format depending on the user's constraints. I think we're a ways off from such a state, but explorations like Tom Murphy's in modal logic are helping us get there. My next step will be to see how to mix Flapjax with RoR and Erlang: there is redundant code when combining server and client apps, and especially when we want both page-based and rich versions, to perform a conversion, or just get more explicit structure for the purpose of optimizations, and I think there is some recent work that can be used to make most of this pain go away. Reinventing the web app. stack is fun research wise, but there is also beauty to finding the appropriate abstractions to fit together the current well-greased yet hacky one :) - Leo <div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">   2. Re: web programming, continuation, CPS transform, etc.       (Shriram Krishnamurthi) ------------------------------ Message: 2 Date: Thu, 3 May 2007 20:56:16 -0400 From: "Shriram Krishnamurthi" <<a href="mailto:sk@cs.brown.edu">sk@cs.brown.edu</a> > Subject: Re: [plt-scheme] web programming, continuation, CPS         transform, etc. To: YC <<a href="mailto:yinso.chen@gmail.com">yinso.chen@gmail.com</a>> Cc: mzscheme Mailing List <<a href="mailto:plt-scheme@list.cs.brown.edu"> plt-scheme@list.cs.brown.edu</a>>,       "Geoffrey S.         Knauth" <<a href="mailto:gknauth@sunlink.net">gknauth@sunlink.net</a>>, Jay McCarthy <<a href="mailto:jay@cs.brown.edu">jay@cs.brown.edu </a>> Message-ID:         <<a href="mailto:c67d38c30705031756s69abfc59k413e687b2c8b2db0@mail.gmail.com">c67d38c30705031756s69abfc59k413e687b2c8b2db0@mail.gmail.com</a>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > RoR also includes the ajax stack, which scopewise equates to > Flapjax.  Would your RoR competitor encompass Flapjax in the future? For now, no, as you suspect.  It's probably unfair to call this an RoR competitor per se.  I'm interested in making it easy to construct the back-end Web services for now, that's all; the rest needs to be written by hand in Flapjax.  But we have lots of neat features in Flapjax now, such as the ability to provide bidirectional connections between model and view, so we *are* raising the level of abstraction -- just not in the same way RoR does. >  I suspect that you have better tricks in your sleeves than the above > approach for your RoR competitor... true/false? I have no idea.  It's still research. (-: Shriram </blockquote></div>