各种LISP的流行(不错，相对是相对的)Web框架是什么？

解决方案

左派

经常提及UnCommonWeb(UCW)，网址为http://www.common-lisp.net/project/ucw/-目前尚不流行REST，更像Smalltalk的SeaSide一样(但话又说回来，SeaSide很像-时尚)。

汉琴图也很普遍

SymbolicWeb -http：//groups.google.com/group/symbolicweb是另一个值得关注的(但还不是"流行"的)东西。

什么是Weblocks？

Weblocks是一个用Common Lisp编写的基于延续的Web框架。

http://common-lisp.net/project/cl-weblocks/

Lisp-on-lines是基于CLSQL和UCW构建的Web应用程序框架，并提供了与Ruby on Rails相似的应用程序开发模型。现在可以在http://versions.tech.coop/lisp-on-lines/上找到它。

http://www.cliki.net/lisp-on-lines

http://kevin.casa.cavewallarts.com/LISP/LOL/lol.html

PLT Scheme具有内置的基于连续性的Web服务器。

更新：PLT计划现在称为球拍。

大多数(也许是所有)众所周知的Common Lisp Web框架已经被提及，所以我只添加一些注释。

在大多数人的意义上，Hunchentoot并不是一个" Web框架"。这是一个HTTP服务器(一个非常好的服务器)。

德鲁·克兰普西(Drew Crampsie)的《 Lisp on Lines》看起来非常有前途，但我不确定它的进展如何。我一直在等待听到一个公告。

Marco Baringer的UnCommon Web基于许多著名的CL实施：Allegro CL，CMUCL，Clozure CL(以前称为OpenMCL)，GNU clisp和SBCL。唯一缺少的主要是LispWorks。我不知道这是否意味着它尚未经过测试可以工作，或者是否已知无法正常工作，或者是什么？但如果它可以在所有其他方言上运行，则使其在任何其他方言上运行可能很容易。

对于Clojure，我们可以尝试Compojure。

对于Clojure，我们可以尝试Webjure。

普通口齿不清

已经提到了许多常见的犯罪嫌疑人(Hunchentoot，UCW，LoL)。
Franz可用于Allegro Common Lisp(并移植到其他Lisps)：

• 在较低级别(自己处理HTTP请求)，AllegroServe。
• 在更高级别(更多是"框架")，WebActions。

两者都是开源的。我倾向于使用AllegroServe，在需要它们时将其分解为实用程序，但是有些人真的很喜欢WebActions。

我使用Araneida已经有一段时间了，我喜欢AllegroServe的风格，但是自2006年以来就一直没有对其进行过维护。

我已经对Lisp的一个很好的Web框架进行了广泛的搜索，但发现它们几乎都无法访问。 UCW的体系结构对我来说似乎不是很自然(我不记得为什么；自从我研究它以来已经有一段时间了)，并且不再维护KPAX。

符号网络看起来非常有趣，我认为Weblocks是最有趣的，但是Weblocks的文档并不十分完善，对于新手来说可能非常吓人。我上次查看SymbolicWeb时还不成熟，但此后可能会有所发展。今天的功能页面看起来不错。

我们可以采取不同的方法。如果我们希望使用纯Lisp的方法，则可以：

• 如果我们能熟练地阅读代码并理解续篇，则可以尝试使用带有Hunchentoot后端的Weblocks(Weblocks对Hunchentoot的依赖关系尚未抽象)。一两个月之内就应该有一份真正的用户手册，但是对于任何OSS项目，这样的承诺都是粗略的。
• 同样，我们可以尝试SymbolicWeb。 [更新：没关系，该项目不再存在]
• 自己动手。认真地说-有cl-who可以帮助HTML生成，有可用的javascript和json库，usockets，elephant，cl-sql，hunchentoot，aserve和许多可以一起烘焙的实用程序库。

如果我们可以使用混合方法，那么我目前正在尝试这种方法：我已经为Qooxdoo编写了Lisp JSON-RPC后端，因此我可以通过诸如Cherokee和让Cherokee可以根据需要将与Lisp中运行的后端json-rpc服务器的连接分配出去。非常非常可扩展。我还没有弄清楚问题和挑战，但是开始工作很简单。我认为json库使后端工作变得愚蠢而简单，实际上，Qooxdoo本身更难(但是我不是JS开发人员)。

我还将要从allegro中检查WebAction，因为对付费支持有一定的吸引力，更不用说Allegro可能是最好的CL实现(他的Kennyness使用它:-)。

回复：SymbolicWeb(及其夸张的灭亡)

Gitorious上的SymbolicWeb项目页面和Wikipedia上的SymbolicWeb文章。 Google网上论坛页面肯定已经死了(并且未存档？)，但Gitorious树显示最近在2010年4月29日签到。在我撰写本文时，加强了"偶尔"的限定词:-)。)

(注意：我不是SymbolicWeb用户。我在阅读此线程时只是跟踪SymbolicWeb链接。)