First off, I like the elegancy of the CPS approach, however...
The continuation-passing approach doesn't scale. Not only to multiple machines, as papersmith points out, but on a single machine. news.yc has (had?) problems with a theoretical DoS which pg has acknowledged in email: http://news.ycombinator.com/comments?id=18083 (post formatting corrupted by pg hiding then unhiding the post).
Dave Roberts has an interesting write-up of the approach: http://www.findinglisp.com/blog/2004/11/web-application-design-rest-of-story.html In email he said that talking about it with pg one time, pg made clear that for Viaweb it was only used for the web site the merchants accessed, not the many hoards of customers who accessed "normal" links, and only the links on the current page for that merchant worked, i.e. if you pressed the browser's Back button all the links on that old page were broken and the server would just present you with the current page again. In summation Dave said if your site is small enough continuations may work fine, but if it's meant to be the next big thing use REST and I agree.
This is probably the neatest web framework of any language I've used. The only downside I can see is that it stores the app states in sessions in the form of closures, and since you can't easily serialize closures, each session is stuck on one machine. So if you want to scale to multiple machines, each user will have to use a single machine for the entirety of the session, which could result in load imbalance with traffic-heavy sites. This is only in theory, it would be nice to hear some stories where sticky-session has not been a problem in scaling.
This looks exactly like Perl's CGI.pm or CGI::Simple to me.
That's not a bad thing. Most folks working other languages would do well to pick the most popular CPAN module for a given area and re-implement it in their preferred language as a way to get a jump on development. As some folks have done with Template::Toolkit for other languages.
But, I'm not sure I see what's interesting about UCW, other than being written in Lisp.
UCW is based on continuations and allows you to code your web apps in a manner more like a desktop app. It was originally like a Lisp verison of Seaside, although I think it has evolved into its own personality. It's nothing like CGI.pm.
This is much closer to the truth. AFAIK it uses some heavy-duty macrology and such-like to mechanically transform a subset of Lisp to continuation-passing style. It also has the obligatory HTML/Javascript generation stuff. It has been used for real-life client work but nothing high-traffic.
I didn't see any continuations in the first couple of pages of the docs. They merely looked like lisp versions of the examples for CGI.pm. If those first few examples aren't representative of UCW, then I'll happily retract my assertion.
It's an unnecessary detail (the continuation I mean) there is no need to bother the user of the framework with that detail. It's hidden in code like this...
Question excellent tobad represent pages/widgets. Here question probably has a form which has a field called answer and the submit binds to the action are-you-sure.
Thing to note: The workflow is defined easily and is very clear.
Continuation-style webapps are supposed to make programming easier, but doesn't that contradict REST principles for webapps? I think it would be preferable to have a good framework (for lisp!) that supported REST-style. I would expect the continuations-style holding session state would lead to problems once you get past prototyping. Also, can you make cool urls for bookmarking?
Actually bookmarking is an issue with what I am doing so for now I'm using a redirect to get the url cleaned up. For example if you want to get timetable from London to Brighton then you search and the results are on a url like /timetable/london/brighton.
There is a way to change the url but that only half works for me. I still get urls like timetable/?from=london&to=brighton
AFAIK the continuation-passing style is designed to write desktop-like web apps with interactions too complex to model on plain HTTP. But if you have to use static URLs, you can still explicitly specify them.
The continuation-passing approach doesn't scale. Not only to multiple machines, as papersmith points out, but on a single machine. news.yc has (had?) problems with a theoretical DoS which pg has acknowledged in email: http://news.ycombinator.com/comments?id=18083 (post formatting corrupted by pg hiding then unhiding the post).
Dave Roberts has an interesting write-up of the approach: http://www.findinglisp.com/blog/2004/11/web-application-design-rest-of-story.html In email he said that talking about it with pg one time, pg made clear that for Viaweb it was only used for the web site the merchants accessed, not the many hoards of customers who accessed "normal" links, and only the links on the current page for that merchant worked, i.e. if you pressed the browser's Back button all the links on that old page were broken and the server would just present you with the current page again. In summation Dave said if your site is small enough continuations may work fine, but if it's meant to be the next big thing use REST and I agree.